Displaying time and timezone information to the us

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

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 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

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 5

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 6

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.