How dates and times are shown in a UI depend on the context they are shown in.
I suggest we follow this concept for handling timezones:
- Dates and times are stored in a clearly defined timezone on the server. There's a fallback timezone, in case that timezone is not set.
- In AdminCentral, an editor has the choice to see all dates and times in either the server time zone or in a time zone of his choice. He specifies his preferences in the user settings dialog (see below).
- In all editorial or admin apps such as Pages, Categories, Security, the timezone used is the one set by the user.
- In all development or technical apps such as JCR tools, whenever we show or dump raw data such as nodes in the JCR config tree, the timezone used is the one of the server.
- On the actual website, the choice should be up to site developer/customer/partner. He should have the possibility and no obstacles, to show dates and times:
- in the timezone as they are stored on the server
- in a hard-coded timezone defined for the site (e.g. a car hiring company in central europe hard codes the timezone to CET).
- in the timezone guessed from the location a visitor surfs from or derived from browser settings.
We need to add a preference setting to pick the timezone we want dates and times to appear in. While doing so, we also clean up the dialog and group all settings it offers.
To pick a timezone, the user has the option to:
- pick the timezone as currently configured and set on the server. The server's timezone is shown.
- specify a timezone of her choice.
The list of timezones should be comprehensive and include major cities. A minimum set could only offer relative settings (e.g. "GMT +1h", "GMT +2h" or "UST -5h"), although that's user friendly.
In the List and Tree view, I suggest we continue not showing any timezone independant of the user's preferences to avoid sacrifying space for repetitive, clear information. Instead, we can reveal timezone information in a tooltip, if a user hovers or tap on a date value.