We have to present a list of time zones to the user from which they select the one that applies to them.

We have a choice about how we display this information - either:

Time zone name (Offset)


(offset) Time zone name

Windows uses the latter approach, but I'm not sure.

How do people pick their time zone? Do they look for the name (Central European Time, Pacific Time, etc.) or do they use the offset from GMT or UTC?

This leads onto a supplementary question - should the offset be displayed relative to GMT or UTC? Windows XP used GMT whereas Windows 7 is using UTC - or at least that's the case for the machine I'm using.

  • What task is the user trying to perform? Why are you forced into choosing this way? People tend to pick time zones based on location ("here")--can't you give them some access to that instead? Commented Apr 4, 2011 at 14:11
  • @Alex - the application is a store manager. The head office admin staff will be selecting the time zone for stores they are setting up, so there is no "here" unfortunately.
    – ChrisF
    Commented Apr 4, 2011 at 14:13
  • Do you already know the location of the store? Can you guess the possibilities for time zone from that? Commented Apr 4, 2011 at 14:17
  • @Alex - not necessarily. While the address is a required field there's no guarantee the user has entered the values either correctly or in a way we can reliably work out the time zone. Good idea though.
    – ChrisF
    Commented Apr 4, 2011 at 14:20

6 Answers 6


In the few times I've done this, we've always followed the format: Time Zone Name (offset)

In very brief user testing, we found that users looked primarily for their time zone name and didn't always know the offset from GMT (or UTC). So we have that field first. I don't believe our users knew (or cared) about whether the offset should be from GMT or UTC.

This was for a form available to a broad public audience in the US. Our findings might not be the same if your audience is more technical or outside the US.

  • This chimes with my thoughts, but I wanted to make sure I wasn't missing something.
    – ChrisF
    Commented Apr 1, 2011 at 17:26
  • @Voodoo: By "primarily for their time zone name", do you mean their location or acronyms such as GMT, EST, EDT, BST etc.?
    – Dan W
    Commented Feb 24, 2015 at 0:21
  • We spelled out the time zone name -- "Pacific Time", "Mountain Time", etc. I can't recall offhand if we made the name conditional to add "Daylight" vs "Standard" for the zones that have daylight savings.
    – Voodoo
    Commented Feb 26, 2015 at 19:25

I don't know where I saw it, but the best timezone picker I ever saw allowed you to pick a map that had shaded bands for timezones allowing you to pick the band. It was the easiest I've ever seen and the most intuitive.

Ubuntu for example: enter image description here

  • 2
    And make the website/app usable just for people who know geography? It's cool and neat, but I wouldn't go there. Commented Apr 2, 2011 at 7:15
  • 1
    Something like this is also a little over the top for our application.
    – ChrisF
    Commented Apr 4, 2011 at 11:38
  • 2
    It's definitely not right for every application, but I think you will find that majority of connected users would have an easier time with this than picking a -5:00 timezone. Realistically - you could do an IP to grab the initial timezone in many instances and ask if this is correct. That takes it one more step into the easy to use category. Cities not numbers are what most users will want to use. Commented Apr 5, 2011 at 21:21
  • I would like to heavily second Chris Kluis' opinion. Commented May 9, 2011 at 23:25
  • Nice, I wonder if we have something like that implemented as a jQuery plugin.
    – Henry
    Commented May 16, 2012 at 15:52

One other alternative I could see is integration with location-data and something like the Google-maps api that can handle typed-in locations quite reasonably. I've not yet seen this integrated in timezone pickers, but it is used in weather apps. (I am not sure it is the best alternative, but I wanted to make it available anyway.)


Speaking as someone who does this on a regular basis (Israel, UTC +02:00), I can tell you how it works for me.

I think the Windows approach is great, because only the zones used as standards really have names, and the others are denoted by different cities. There's a huge number of cities, and they share a relatively small number of timezones (about 30 - turns out that the differences are not always by a round hour, and sometimes can be half an hour).

The offsets are very easy to navigate, they go from -12 to +13 in a clear increasing order. So first I find my offset, +02, and then within that group I find the city that's relevant to me (this matters because of different daylight time saving policies in different countries). Now, you could do it by city in alphabetical order, and I'd have it easy since Israel is a small country. But if I lived in Russia or India, with a dozen cities on the list for each country, I'd have a hard time guessing which city you decided to list, and which of them is closest to my location.

  • We'd be listing them as they come out from Windows but with the name first. So instead of seeing "(GMT+2:00) Beirut" you'd see "Beirut (GMT+2:00)"
    – ChrisF
    Commented Apr 1, 2011 at 18:32
  • Interesting insight. It depends on the audience - as I said in my answer, people in the US are definitely NOT familiar with their offset amount. It helps to organize them in order by offset amount, but in our case listing the time zone name first was preferred.
    – Voodoo
    Commented Apr 1, 2011 at 18:32
  • @Chris, the problem is that many major cities and capitals share the same offset. E.g.: (UTC +01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna. So if you flatten the list, it's going to be very, very large. But then again, I don't know your app and the selection of cities you offer. Commented Apr 1, 2011 at 19:17
  • @Vitally - we're pulling the list of time zones from Windows but I see what you mean.
    – ChrisF
    Commented Apr 1, 2011 at 19:33

Most people will be looking for the time zone names, or cities, and not specifically for the number, so that could be a reason to list the offsets last.

On the other hand, offset first also makes sense to me, for this is the variable that determines the list ordering. It makes the ordering explicit, and if the amount of space for you list is wide enough there is still enough space for the full time zone names.

Personally I'd be looking for "Amsterdam (GMT+1)" and am always confused about daylight saving time, so if the place isn't listed I wouldn't know whether to choose GMT+1 or GMT+2. I'm less familiar with the abbreviation UTC, but for an audience from the US this could be different.

A very friendly and straightforward type of feedback for time zone settings is to show the local time according to the selected time zone. Users can simply look at the clock and verify if the displayed time matches their time.


If it's a dropdown many users search through letter pressing. This is only doable in the first form. But again, if you expand the dropdown is much more easy to find things in the second format.

I'd suggest user (A/B) testing :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.