41

The list of time zones is rather long, lots of duplication, and not very friendly to programmers let alone end-users.

Is there a way to shorten the list to something friendlier and sufficient for 80%+ of users? But then how shall one decide which are the popular Tz?

The list in Windows seems pretty good, but I'm not sure if that's a good list to model after. It is interesting because DST is optional, is that why the list can be that short?

I'm in Pacific Daylight Time (PDT). JS's getTimezoneOffset() returns 420 ==> offset -7. If I use the time zones list above, how would one tell its US/Pacific (-8)?

Furthermore, what are the popular names for time zones? US/Pacific or Canada/Pacific sure sounds friendlier then America/Los_Angeles or America/Vancouver.

Lastly, how are the 2 timezones above different? Can they be safely grouped together and just use America/Los_Angeles in the app? How shall one group time zones together?

Improve this question
6
  • 2
    Your question is very wide ranging; you would get better answers if you could narrow the focus some. For example, the part about 'US/Pacific' vs 'America/Los_Angelas' is a rather different question than 'Is there a way to shorten the list to something friendlier'.
    – Myrddin Emrys
    May 16, 2012 at 6:15
  • 3
    Yes, they are all parts of the problem of how to design the best UI/UX for assisting an end-user to pick his/her correct timezone.
    – Henry
    May 16, 2012 at 7:26
  • 1
    Related - ux.stackexchange.com/questions/5740/…
    – ChrisF
    May 16, 2012 at 8:40
  • 1
    might want to check out stackoverflow.com/a/28602292/1335165
    – Lucky Soni
    Feb 19, 2015 at 9:18
  • 1
    For some in the western US, expecting us to voluntarily associate ourselves with "America/Los_Angeles" is pretty darned unfriendly, and I imagine the same holds true in many another locale. Much better to have the actual time zone names, or a (perhaps zoomable) map to select from.
    – jamesqf
    Apr 23, 2015 at 19:45

10 Answers 10

Reset to default
19

The list you refer to contains tons of duplicates. If you look at the list of time zones in Wikipedia you'll find 40 different time zones. Since you were asking for a 80% solution it's safe to cut the list by 12 (the ones with a 30 or 45 minutes offset. That leaves you with "only" 28 options. The list you've shown contains many duplicates. Still you're left with the question about the UX of selecting the time zone...

One way to do it might be to have two time zone shortcuts, the offset and some example cities:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Why this way?

About names:
Users sometimes know the names of the time zones, e.g. PDT or CET. But there are local flavors like MEZ (a German term) or you'll find users that don't know these terms at all. The standard is UTC (Universal Time Coordinated) but many people still know this as GMT (Greenwich Mean Time).

Countries vs. Cities as examples:
Using examples of locations in time zones is a good idea. Using countries is more generic and would be good but doesn't work e.g. for the US. To be consistent in the selection using cities is the better way.

Another option:

If you have the development capacity, you could just offer an input field and ask people to enter a city or country. Depending on what they type you select a time zone (on submit, only if it's a unique hit) or suggest a subset of time zones that match the users input:

mockup

download bmml source

Depending on your use cases and application there might be another way. If your users enter their location and/or postal address anyway the best solution then is to not make them select manually but to pre-populate this information for them based on their former input.

Improve this answer
7
  • 2
    Thank you! I like the very last point you make about smartly select one for them based on their address. Great answer!
    – Henry
    May 16, 2012 at 8:06
  • 15
    I would strongly caution against aggregating many cities into a single value just because their offsets are currently the same. This will very often lead to incorrect results for your users. The reason that there are so many different zones is largely because they will change at different times. For example, for part of the year London and Stockholm will have the same GMT offset, but not for the whole year since they go into DayLight Savings at different points.
    – Sean Colombo
    Jul 7, 2016 at 17:29
  • 1
    @SeanColombo I think your example is incorrect (under current rules, essentially the whole of Europe switches simultaneously - see en.wikipedia.org/wiki/Daylight_saving_time_by_country). London and Stockholm certainly do. However, this is further confused by the fact that historically time zones have changed, daylight savings switchover dates have changed, etc. This answer is overly simplistic for many cases - knowing the user's location more precisely is important. See stackoverflow.com/q/6841333/27641 for an example.
    – Andrew Ferrier
    May 24, 2017 at 12:51
  • 1
    @AndrewFerrier thank you! Didn't know they were the same now. Perhaps I should have used the states of Phoenix, Arizona (which doesn't have daylight savings) and Santa Fe, New Mexico; which should overlap during part of the year but not during the other part. Hopefully the point is clear though... thanks also, for the link to another good explanation!
    – Sean Colombo
    May 24, 2017 at 14:06
  • 1
    For anyone still reading this in 2020, I made self-updating "simplified" time zone lists: github.com/vvo/tzdb. My goal was to be able to reproduce the Google Calendar time zone selector where they show time zone offset names (like Pacific Time - Los Angeles) and they try to group time zones. I decided to group timezones whenever they were in the same country, same offset, same dst rules. Good luck!
    – vvo
    Jun 17, 2020 at 12:49
15

A map with the title "Where are you", and when user selects a zone update a text with current time (to verify) "In your place it is 08:15 AM".

enter image description here

Improve this answer
6
  • 2
    I like this approach, like the ubuntu installer: phynformatik.de/wordpress/wp-content/uploads/2010/06/…
    – Thijs
    May 15, 2014 at 12:21
  • 2
    Excellent solution to this problem! Its simple enough that a 4th grader can effectively select where they live. Combined with a "Where you live it is 8:15 am right now" you have a simple and effective way of providing feedback. I was about to write this answer myself until you posted it.
    – Benjamin S
    Apr 23, 2015 at 19:43
  • 2
    This is very similar to what Mac OS does the first time you start the operating system.
    – Adriano
    Oct 7, 2021 at 22:44
  • Funny thing that I don't remember knowing that MacOS or Ubuntu use that. Maybe it remains in my memory, or maybe it's a "common sense" solution. 🤔 @Adriano
    – ESL
    Oct 8, 2021 at 6:31
  • It might be hard for people who aren't used to reading world maps, and there are plenty of those... Maybe both this and the city search solution.
    – Arkan Tanriwa
    Oct 8, 2021 at 7:25
10

getTimezoneOffset()

The simplest solution should be to call getTimezoneOffset() on a every login or page load, and not burden the user. I don’t know why it isn’t working for you; I thought getTimezoneOffset() accurately accounts for geographic location and local DST practice. Maybe you should investigate this some more to understand when, why, and how much getTimezoneOffset() gives errors.

Localize Zones

If you have to show the users a list of time zones, then try filtering the list and adjusting the names for their locality, based either on their IP address or user-supplied country name. It becomes part of more general globalization/localization you need to do with your product.

Use Time, not Time Zone

Rather than ask the user for their time zone, perhaps it’s better to ask them for their local time and calculate a correction by comparing it to getTimezoneOffset() and UTC. In other words, displayed time = UTC + getTimezoneOffset() + user_supplied_correction. I’d expect that entering the time to the nearest 15 minutes to be easier than choosing among dozens of time zones, many of which would be unfamiliar. Use getTimezoneOffset() to set the default time and perhaps most of your users won’t even have to enter the time, or, at most, they make only a slight change.

Daylight Saving Time Practices

Getting local DST practices is harder. You cannot expect users to know the exact date that DST changes for them, and I wouldn’t even trust them to know which time of the year is DST for them. However, maybe getTimezoneOffset() does sufficiently accurately indicate local DST practices, which I believe vary less than time zones. If so, then using UTC + getTimezoneOffset() + user_supplied_correction would take care of it.

If getTimezoneOffset() just isn’t accurate for that, you need a table or service that relates location to DST practice. Again, maybe you can use the users' IP address, or use the user’s country (and maybe state/province), assuming you’re asking for that information anyway. It won’t be perfect, but maybe it’s acceptable if it works for the vast majority of your users. Given you’ve supplied an easy way for users to correct the time, the few edge case users always have the option of manually adjusting for DST, so you won’t be forcing them to live with the wrong time.

Calendar Events

The above assumes you’re concerned with correctly displaying the local time. For entering a calendar event that can occur in another time zone, the name of the time zone in your dropdown should match how time zones are expressed to the user in the information sources that tell them about the events. For example, if the user sees or hears stuff like “Webinar 2:00pm Pacific Time,” then one option is “Pacific Time.” You’ll need to do some research to find out what those expressions are; it probably varies with the user population. Geeks might use UTC+/-X, but maybe no one else does. Sources used by pilots often use UTC regardless of the location (e.g., NOTAMs). Maybe different localities have different names for the same time zones.

It may be helpful to redundantly indicate the offset from the user’s local time (not UTC) –for example, “Pacific Time (3 hrs earlier)”. The user may have some idea what the offset is, so this would help them confirm their choice. Of course the user should always have the option of entering the equivalent local time for cases when they know the offset. Also, in some cases it’ll be easier to get the offset than to identify the time zone (e.g., call the person at the location the event will occur and ask them what the local time is).

It may make sense for the dropdown to list only the 5-15 most commonly used time zones (probably the times zone geographically closest to the user’s time zone), and include a More option to open a dialog or page listing time zones in detail (e.g., supplemented with a map).

Improve this answer
4
  • 1
    Thank you. I think getTimezoneOffset() may work fine for visitor, but in a calendar app, the calendar needs to know what timezone an event is happening in, and the owner is responsible for setting the timezone of the calendar, so that the offset can be calculated.
    – Henry
    May 16, 2012 at 15:39
  • I liked the Use Time, not Time Zone solution, but then if I'm now at -7, how would I know if I'm actually -8 in DST, or -7 in Standard Time?
    – Henry
    May 16, 2012 at 15:40
  • @Henry: I’ve added text about calendar events. As for DST, you assume getTimezoneOffset() handles DST correctly, but is wrong on the precise geographic location. For example, it thinks you’re in Nevada when you’re actually in Utah. Both NV and UT use the same DST rules, so UTC + getTimezoneOffset() + user_supplied_correction will still adjust for DST correctly. Study of the getTimezoneOffset() problem will determine if this results in acceptably few cases where users will need to adjust DST manually (e.g., getTimezoneOffset confuses AZ with UT).
    – Michael Zuschlag
    May 17, 2012 at 12:51
  • This might not work correctly in some cases especially for people using VPNs or in an enterprise environment, there it might obscure your actual time zone. In anycase it can still be used as good default. Also check out this study: nngroup.com/articles/time-zone-selectors
    – Andi
    20 hours ago
4

You may be trying to solve the wrong problem.

I would try to select a sensible option for the user or at least filter the list or before reducing or editing options. As suggested in other answers you should be able to do this through javascript or GeoIP detection.

Improve this answer
2
  • Right, I agree that filtering would be better then hard limiting the list to 80%.
    – Henry
    May 16, 2012 at 15:41
  • AFAIK GeoIP doesn't work for IPv6. HTML5's geolocation might be a slightly better solution.
    – Henry
    May 16, 2012 at 15:42
4

If this problem is being solved for a website, and its about displaying some event time in local time for every user, then you may like this solution: we never ask our users to enter thier timezone. Instead we store time in UTC and convert it to local time automatically when it come to displaying data.

This conversion has to be done on client side since there is no way to determine UTC offset on server side (unless you managed to detect offset ealier :) As Michael Zuschlag mentioned JS getTimezoneOffset() works great.

Also, there is a great feature in Date object, that converts time to local timezone automatically: (C#)


JavaScriptSerializer serializer = new JavaScriptSerializer();
DateTime now = DateTime.Now;
DateTime utcNow = now.ToUniversalTime();



Console.WriteLine(now);
Console.WriteLine(utcNow);
Console.WriteLine(serializer.Serialize(utcNow));

output: 


17.05.2012 9:16:08
17.05.2012 5:16:08
"/Date(1337231768190)/"

In browser: 


alert(new Date(1337231768190));

output: note how utc time got converted to local time 


Thu May 17 2012 09:16:08 GMT+0400 (...)

Improve this answer
2
  • Thx, so far do you think getTimezoneOffset() is reliable for your users? Does it work well on mobile devices?
    – Henry
    May 16, 2012 at 15:50
  • Yep, we are processing passport data, where no errors allowed, and its working in all popular browsers. Also, there is a cool feature of Date object: when you create new date object from integer representation of date, date will be converted to local timezone automatically.
    – ADOConnection
    May 17, 2012 at 5:15
3

The most user friendly approach would be to determine the users time zone for them. One less field for a potential user to fill out.

Take a look at this project: https://bitbucket.org/pellepim/jstimezonedetect

It uses JavaScript to determine the machines time zone. It provides an identifier like 'America/New_York'.

When a user creates an account, get their time zone via JavaScript and store it. Whenever the user launches the web app, update their time zone in case it has changed.

If you need to support users who have JavaScript disabled, things will get a little more complicated. Perhaps you only show a time zone field for those users.

Improve this answer
2

Put a multiple options for one timezone. -8 Pacific time -8 Los Angeles and so on..

Let users choose based on big cities and timezone.

Improve this answer
1
  • If you look at the list there are 9 timezones with (-8 offset). Yet I'm not sure which one have Day Light Saving which one don't, and I'm not sure if the ones that have Day Light Saving follow the same switching schedule, that's the problem. Thx
    – Henry
    May 16, 2012 at 7:29
2

Revisited this question again and I think Google has done a pretty good job. Timezone is first narrowed down by country.

https://support.google.com/calendar/answer/37064?hl=en

Improve this answer
1
  • thing is, there are a whole lot of countries and each might have more than 1 zone. I am thinking continent, then region, e.g. North America then Central.
    – Ronnie Royston
    Sep 26, 2016 at 18:43
2

Even I am a tad late to the party, I wanted to share our approach to this, which is partly derived from answers here and in https://stackoverflow.com/questions/1727077/generating-a-drop-down-list-of-timezones-with-php/28602292#28602292 .

We group equivalent timezones, name them by the largest cities and prefix them by the current time in that timezone.

You can read here how we did it and how it performs: https://medium.com/design-bootcamp/the-ux-of-timezones-7476a9685238

list of timezones

Improve this answer
1

While the click the map approach is very nice I wonder about rendering across device types. A more basic way would be to ask user for continent, then for region. A pair of HTML select inputs is all you really need.

A JSON encoded list of continents and regions is available on my CDN https://rack.pub/cdn/timezones.json. A working UTC timestamp generator is viewable https://rack.pub/timestamp.

{
    "asia": {
        "Afghanistan":"UTC+04:30",
        "Armenia":"UTC+04:00",
        ...

enter image description here

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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