How to make selecting a timezone more user-friendly?

  • 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? Someone worked out the tz equivalents here.

    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?

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

    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.

    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.

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


    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:


    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.

    Thank you! I like the very last point you make about smartly select one for them based on their address. Great answer!

    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.

    @SeanColombo I think your example is incorrect (under current rules, essentially the whole of Europe switches simultaneously - see 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 for an example.

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

    @SeanColombo yep nearby US states/counties are a good example in many cases. Irrespective, the point stands; this answer is overly simplistic and will end up with inaccurate results for the end user.

    Africa/Casablanca and Europe/Berlin are good examples for @SeanColombo point. Sometimes they have the same timzone (UTC+1). After both have switched to daylight saving time they have a difference of two hours (UTC+0 vs UTC+2). To get it even worse: They don't switch at the same date.

    For anyone still reading this in 2020, I made self-updating "simplified" time zone lists: 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!

  • 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

    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.

  • 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).

    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.

    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: 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).

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

    Right, I agree that filtering would be better then hard limiting the list to 80%.

    AFAIK GeoIP doesn't work for IPv6. HTML5's geolocation might be a slightly better solution.

  • 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));


    17.05.2012 9:16:08
    17.05.2012 5:16:08

    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 (...)

    Thx, so far do you think `getTimezoneOffset()` is reliable for your users? Does it work well on mobile devices?

    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.

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

    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.

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

    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

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

    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.

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

    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:

    list of timezones

  • 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 A working UTC timestamp generator is viewable

        "asia": {

    enter image description here

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM