Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question
1  
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 '12 at 6:15
2  
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 '12 at 7:26
    
Related - ux.stackexchange.com/questions/5740/… –  ChrisF May 16 '12 at 8:40

7 Answers 7

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.

share|improve this answer
    
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 '12 at 7:29

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.

share|improve this answer
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 '12 at 8:06

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

share|improve this answer
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 '12 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 '12 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 '12 at 12:51

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.

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

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

share|improve this answer
    
Thx, so far do you think getTimezoneOffset() is reliable for your users? Does it work well on mobile devices? –  Henry May 16 '12 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 '12 at 5:15

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.

share|improve this answer

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

share|improve this answer
    
I like this approach, like the ubuntu installer: phynformatik.de/wordpress/wp-content/uploads/2010/06/… –  Thijs May 15 at 12:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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