Creating a user-friendly list of timezones for user-preferences

Question

Below is a snippet of the list of timezones returned from java (I've printed the timezone offset, timezone ID, and long name, using JodaTime).

(GMT-10:00) HST, Hawaii Standard Time     
(GMT-10:00) Pacific/Apia, -10:00
(GMT-10:00) Pacific/Fakaofo, Tokelau Time
(GMT-10:00) Pacific/Honolulu, Hawaii Standard Time
(GMT-10:00) Pacific/Johnston, Hawaii Standard Time

What is the difference between HST, Pacific/Honolulu, and Pacific/Johnston, for example? They all seem to use Hawaii Standard Time, why are there 3 entries in the database?

• My ultimate goal is to just create a list of timezones for user preferences in a web app.

If I use all of the timezones from the tzDatabase the list is long and appears to have effective duplicates (example above). I could just list unique long-form-names such as "Hawaii Standard Time", but then I need to decide how to map it to any one of the timezones that use that same long name.

What do other people do in this case? How do you create a nice user-friendly list of timezones and map them to their relevant java TimeZone?

Answer 1

I think you are making the assumption that "user-friendly" means to show them a small list. The fact is though that all of those time zones are used by someone, somewhere. They may look the same to you but they often have slightly different behaviour. I live in Saskatchewan and we have our own version of CST. The long name is only "Central Standard Time" but we don't use DST so for half of the year, we don't line up with real CST. There is even one small area of Saskatchewan which has a 15 min difference in the time. Even if they seem the same, they are different and I think you should allow the users to select from the whole list.

Trying to intelligently shorten the list might be comparable to not listing all possible currency codes when allowing a user to select a preferred currency. Yes, there may only be a handful of people who use certain ones. Sure, there may be some with the same conversion rates currently. In the end, let the user decide what they care about.

One solution for showing large lists or potentially un-important data with only a few items of real interest: Determine the commonly used ones first and then separate them to the top of the list. This can be seen on various websites for selecting Country, for example:

Canada United States ------------------ Argentina Australia ... 

This strategy is also often used for my previous example of currency. It could look something like this for time-zones (If your main user base is in North America):

EST CST MST PST ------------------ Hawaii Saskatchewan ... 

Remember though, this will require you to manually, pre-determine what the common time zones are.

I feel the best approach is to simply list all timezones, sorted by offset because most people will know where to find there zone based on offset. For instance, I always look first for "-6:00", not Saskatchewan. Hope this helps!

Answer 2

The CLDR data contains a list of "important" time-zones and can probably be used to pick the ones to display. (I remember something else, but this is the best I can find now)

Multiple time zone ids will exist for the same place if the data was different in the past, or if the place has been renamed (the alias feature in the time-zone data). Removing the backward file when compiling the time-zone data would remove most aliases.

Answer 3

Whether or not the timezone uses daylight savings time is probably the most common difference.