Displaying time and timezone information to the user (what, not how)

Question

(This is a question about the UI rather than the technology required to do it)

What is the clearest way to display a time for events occurring in different timezones

Answer 1

The strategy should be that times in the UI -- when shown to or entered by the user -- are in the user's own timezone.

In the application on the other hand, i.e. in Ruby code and in the database, times are always kept in the UTC timezone.

Your job then becomes to allow the user to select a timezone, and then to convert back and forth between this timezone and the UTC timezone as needed.

This article illustrates how to do so in a Rails environment.

That implies to be able to retrieve the user timezone or to have stored that timezone in a 'user' table.

Answer 2

Try an old-style newsroom graphic, where you have clocks labeled "New York", "London", "Tokyo" and then "Papua, New Guinea" or wherever your particular viewer is located. You can make the clocks analog or digital or both.

No one will be confused by this, whereas I don't think most people really know what GMT+7 (or whatever) means.

Answer 3

Display the local time and the offset like this 15:18 GMT+1

Answer 4

best thing to do is to store all date/time information in UTC and then display times offset to the users time. .NET has all kinds of support for this - most other environments do too for that matter. someone entering data in London at 7am should show as 1am or 2am EDT. best part about UTC is that it avoids all te screwy things with daylight savings times or lack thereof when you are in places that dont have it eg. korea, india vs the new offsets for North America.

I like the 24h time such as 15:30 EDT but I am sure there are those out there that work in 12H mode. make that an option for sure.

Answer 5

This is a terribly context-sensitive situation. I'd like to build on the suggestions of postos and tvanfosson. I don't think names of cities and countries are needed except to help people set their local time and maybe in a dialog for setting times that might be for other locations when they only know the desired local time (big challenge to not overwhelm/distract users with what is clutter to them).

If a location is associated with the time, then the date and time at that location is often appropriate (e.g., when speaking of market closings, events, trip arrivals and departures, and so on). I favor the idea that a tool-tip is available for translating it into (1) gmt and (2) the apparent local time of the user who is seeing the interface. Offsets are useful too, and also the date when midnight crossings are involved.

I also concur that the time zone should be explicit as a cue that it might not be the local time. Furthermore, even when a local time is shown without timezone, I think that tool-tip is still important. (Especially when someone traveling with a lap-top may keep their homebase timezone setting.)

Bonus attention to detail: Dealing with time shifts for summer time, daylight savings, etc., and their difference between locations (not every place has summer time, not every place makes the change at the same time) and between points of time (into the future especially).

Answer 6

Display it with the Timezone abreviation

Instead of

15:18 GMT+1

Show it as Central European Time

15:18 CET 

People are More used to seeing their own timezone