There are multiple ideas open already on timezones, but I think this one goes further: Date fields in Tridion today have a date/time picker, but no way to select indicate a timezone. They should be made timezone aware.

With editors across the globe, recording dates in content and content life cycles in metadata (think: start/end date field, expiration date field), it becomes ambiguous what these timestamps mean: are those timestamps relative against server local time, editor local time, or some other reference point?

For example, for the US market, I have editors in Pacific time scheduling media playlists for digital displays in East Coast (NY) and Central time (Chicago). It would help if these users can say: "from 10am-11am East Coast time, show this." for New York, and for Chicago: "from 10am-11am Central, show that." I.e. to do their scheduling relative to where the outlet is, without having to think about where they are themselves, or where the server is located.

The timezone selector in the Date/time picker UI would (in my mind) default to server timezone, with an override in user preferences (to set the author's preferred timezone: Pacific in above example). From there, the author can adjust/select for that particular timestamp: Central or East Coast).

Under the hood, CM either records the date with timezone designator, or converts the date to UTC. On CoreService, the timezone is set by including a timezone designator or UTC-offset using existing the ISO8601 format.

System timestamps (last modified, last published, etc.) are either always in UTC or include a timezone designator to communicate UTC-offset of the CM server clock (again using current ISO8601). Action scheduling (publishing, etc.) is per user's preferred timezone as described in other ideas.

For backwards compatibility: existing timestamps (having an unknown timezone) will remain ambigious "local time" by not including the ISO8601 UTC offset/timezone designator.