Unambiguous way to display timezone information in a compact manner

Question

When displaying a listing of events, each with their own date, time, and timezone, I'd like to present the timezone that the given event has been assigned. However, there is potentially a lot of information to convey. Two options I've considered are:

1. UTC offset - e.g. 2010-08-16 4:15 pm (+5:00 GMT)
2. Timezone abbreviation - e.g. 2010-08-16 4:15 pm EST

My problems with these are:

1. As soon as I see the plus (or minus) with the GMT offset, I feel like I need to do the math. How does the user know if the displayed time has already been adjusted? Also, if daylight saving is in effect for that timezone, this is misleading.
2. There's information missing here. There are a lot of timezones and I have yet to find an authoritative list of timezone abbreviations. The closest seems to be this TimeAndDate.com list. Alternatively, there is the tz database list, but I don't think users would know what to do with this.

So, my question is, how can I convey which timezone a given event occurs in, given that there is going to be a list of them on the screen?

Answer 1

Time zones are a great example of horrible UX in everyday concepts. It's not DMMT: if you tell me an event is at 7pm GMT+4, then first I have to think of where I am in relation to GMT, and then I have to add 4 hours. What a mess!

Instead, think of the different things you can do with time if you're able to calculate or design. For instance:

• Show a map with a pin in your location and a pin in the event's location with a ticking digital clock above each pin showing what time it is in each location. This works well if you have an event overview page and you know who the logged in user is.
• Do the work for me and say "(this event takes place at) 3:15 AM on Thursday, your time" in plain English. Or if you're in a table, put "Takes place at (your time)" in the column header and just print "3:15 AM on Thursday" in the cell. This works well for notifications or streams.
• Use relative time to avoid having to be specific (this depends on the use case obviously). If dates are far in the future, who cares what time they are? Just say "in 2 weeks". If they're within a certain margin, get more specific: "in 3h44m". Those time should be relative to the user's time zone.
• Still need to display time zones (for some reason)? Display a map like this one:

And perhaps highlight the time zone the event takes place in when the user hovers over an event in the list. You could even combine that with my first suggestion.

Ideally though, use plain English and rely on real-world metaphors as much as you can to display information. Obviously you have a constraint: you need to show information concisely in a list. But that's the challenge for this design.

Answer 2

One quick comment on using the three letter abbreviations - be careful not to use them as the sole indicator of the timezone since there are cases where timezones have the same three letter abbreviation.

For example EST can mean any of:

• Eastern Summer Time Australia UTC + 11 hours
• Eastern Standard Time Australia UTC + 10 hours
• Eastern Standard Time North America UTC - 5 hours

Answer 3

if your really have to, don't show time zone info but the city associated with the event (or the time zone if no location is provided).

Better, don't show time zones at all. What does it matter if I'm in time zone X, as a user I want it all normalized to my time zone. You loose track of concurrency if you show multiple time zones on one screen.

Ideally you normalize the time zone and provide a simple to view ti in another time zone. So if I want to plan something that some of the participants are in another time zone, let me see when in the day this meeting will be in that other time zone with a simple slider, that moves to countries or to cities around the globe.

Answer 4

I like the abbreviations with the offset.

Tuesday, August 17, 2010 4:30pm EDT (GMT -4)

That allows me to automatically associate with the time zones I am familiar with and do the math for the ones I don't know. Also if you can't find a name for a timezone it doesn't look out of place if you put the offset.

Another bonus to this is during daylight savings time. EST which is GMT -5 becomes GMT -4. By putting the number this will remind me of this.

Another issue though is UTC or GMT. UTC seems to be more correct these days but I am used to GMT, so I prefer that.

Answer 5

When an explicit time offset needs to be displayed, the World Wide Web Consortium generally aligns its standard for time zones with ISO 8601. That is to say, they prefer "[time] UTC(+/-)hh:mm".

Alternatively, if you don't want to use UTC, they suggest using the CLDR unicode library to get "Country/Major City" formatted identifiers (e.g. "America/Los Angeles") which identify the country's daylight savings rules and the relative time.

Answer 6

For letting the user know if the time has already been adjusted - I think you need to be consistent; either all times listed should be adjusted (in which case you probably don't need to have the timezone information displayed) or all times should not be adjusted (in which case the most descriptive timezone information should be used, like +5 GMT).