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

As others have mentioned, I think that if the application is specific or local, then you can omit the timezone, or make other assumptions.

If it is global, then you want to store the data consistently (always UTC), then convert for display. Furthermore, you would want to let the user specify his/her timezone, and possibly also a date and time formatting; either by giving several static options, or giving them the full power to specify a format string, if they're advanced enough to do so.

If you don't want to give options to your users, then a simple HH:MM TZ or HH:MM GMT+/-H seems adequate? Or you could even just display the time local to the server, then in a footnote or FAQ, say "all times are PST" or whatever it is.

As a user, I would prefer maximum configurability, but I suppose I'm biased, being a programmer.

Answer 2

Always display the time in UTC

NB I don't agree with this. I just added it as an option for voting.

Answer 3

You mention packages. The convention in logistics is to always display local times, which is what UPS and the like show in the status history in their track-and-trace data.

If that localtime is not the current users's time zone, then I would consider annotating the time with the time zone, e.g. 09:00 (Europe/Amsterdam).

Note that place names are better than abbreviations, which can be ambiguous. It is up to you to decide whether it is more useful to tell the user where the time is, or what the difference from their time zone is.

One way to to avoid the problem is to just use relative times, e.g. 4 hours ago.

Answer 4

I like GMT+offset (assuming offset will "usually" be the user's time zone). As an additional clue, provide a tooltip listing some cities in that time zone (one per hemisphere), or hyperlink to some page explaining the time zone in more detail.

Answer 5

Having been bitten several times over the years by "small" applications suddenly being either nationwide (in the US, 5 or 6 timezones) or global, I always store datetime data in UTC if possible.

The problem then becomes display, as a number of other post have pointed out.

If a date/time is displayed, and it relates to the location (and locale) of the current user, display it in the user's local time.

If multiple date/times are to be displayed and they relate to different locations (possibly different locales), I've found that the users prefer to see the time displayed in the location's timezone, in 12 hour format.

Think about how airline tickets are printed (at least in the US) - departure and arrival times are displayed in the timezone of the departure city and arrival city. The best itineraries have a "total travel time" or the duration displayed as well.

Ok, so you want to show locale formatted data for the user: How do you determine the locale? For web applications, while locale is present in most HTTP headers, you can't always trust that the locale is set correctly on the user's machine. So we almost always end up either asking the user to set up a profile that includes some data from which we can determine locale (zip/postal code, city/state/country, etc) or to enter something that gives us an idea of where the user actually resides (for either Web apps or 'native' applications)

I have not had to implement this since geo-location via ip address became widely available, but that is not necessarily accurate either.

Note that when I've worked on these applications, my personal settings almost always end up in 24 hour format, UTC, ISO8601 just so I know what time is being displayed to me, regardless of where the user is.

Answer 6

I think this cannot be answered definitively absent a particular application. For example, in an intranet application for all users in the same timezone, you can often omit the timezone completely. For a stock market application, you may want to make the time relative to the timezone of the market. For a social web application, you may want to make the time relative to the user's timezone. I think the general principles that would apply are:

1. If there is a possibility of confusion you should always specify the time zone
2. You should work with your users to find out how they want the time to be displayed.