[tz] Time zone selection

Matt Johnson mj1856 at hotmail.com
Mon Apr 18 16:04:19 UTC 2016

>From the recent thread on Montreal:

> Why does your program expose the timezone names instead of the
> descriptions from zone.tab - in this case, the current description of
> America/Toronto is "Eastern - ON, QC (most areas)"?

I find it frustrating that we continue to give this as general advice.  The problem is, using zone.tab alone (or zone1970.tab) is an incomplete solution.  We tell folks to use not show IDs to their end users, but most platforms and libraries only have methods for iterating the IDs, and those that do show zone.tab comments only show them in English - because that's all that we provide.  To my knowledge, there is no project that maintains localized translations for comments in zone.tab.  Not even CLDR.   So when we tell folks not to show the time zone names - we aren't really giving them a viable alternative.

Have anyone else actually tried to build a multilingual time zone selection control?  I have, and it was extremely difficult.  I'd appreciate feedback, if anyone wants to try it out: http://timezonepickerdemo.azurewebsites.net/   This uses CLDR data for localization, using their generic-long form form.  This is a problem in isolation because, for example, one cannot easily distinguish between America/Phoenix and America/Denver because both have the same generic-long form of "Mountain Time".  Significant other ambiguities exist.  The only solution I've been able to derive is to show "Mountain Time (Phoenix)" and "Mountain Time (Denver)", which is nonstandard by the CLDR spec.

Additionally, one has to consider the context of the scenario.  If I'm only picking a time zone for scheduling future events, it's a bit ridiculous to show the list of Indiana time zones and other historical differences.  Just because we have zone splits going back to 1970 doesn't mean that every application is concerned with data going back that far.   So to handle this concern, I've computed a "threshold date" for each zone, where the zones are identical from the threshold date forward.  That date can be set by the developer of the application to limit the subset of zones to choose from without imposing too much opinion.

I'm curious if anyone else has explored this space before, or used similar techniques?


More information about the tz mailing list