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 to a user? Does your "average" user understand UTC and timezones?

We capture the local time and UTC offset and store it in the database (SQL 2008 DateTimeOffset) for events happening in different timezones. Users are also in a variety of timezones.

I'll suggest a couple of answers below so they can be rated but I'd appreciate alternative suggestions.

EDIT: I'd like to avoid displaying the time in the user's timezone. Users in different timezones will be discussing the same events and if they're local to different timezones, there'll be confusion.

EDIT: I wanted to make the question generic and hopefully useful to more people but for some specific context, this is a web application for tracking parcels (think FedEx). Parcels will cross timezones. Customer support is in the UK but the recipient may be elsewhere.

Answer 1

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

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

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

Answer 4

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 5

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.

Answer 6

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 7

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 8

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 9

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 10

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 11

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 12

What you have described is a situation where the viewer of the page is supporting the customer.

So I recommend that the design focus on the customer perspective. So, the default, or primary display method should be the local time of the customer. If you are using email or IM, you should have some kind of userdirectory as a source. If you are on the phone, then caller ID can be the basis of time conversion.

This is also an example of how the software is only part of, not the entire support offering. The display should allow easy switching to other time zones, and the phone reps should always be trained to ask what time zone they are in before providing any time-based information.

It should also have an option to show the local time at the point of arrival. This allows you to converse with the customer in a seamless and efficient manner:

CU: "When will it arrive?" 
CS: "Based on your phone number, I am assuming you are in EST. The ETA is 8pm". 
CU: "I am traveling in Chicago right now. Can you tell me when I should check back?"
(Phone rep taps a "CST" button on the screen, and the displays convert.) 
CS: "Sir, if the package does not arrive before 9:10pm, your local time, please call us."

Answer 13

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.