[tz] Time zone selection

[Guy Harris]

On Apr 18, 2016, at 9:04 AM, Matt Johnson <mj1856 at hotmail.com> wrote:

> 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?

Apple's built multilingual time zone selectors; one is part of System Preferences on OS X, and one is part of Settings on iOS.  (There are probably others in watchOS and in Apple TV Software/tvOS.)

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

The OS X selector lets you select either by

	1) dragging a blue dot to the appropriate location - it shows a world map, with some region containing the dot highlighted (it's not a tzdb zone, as it includes more than one tzdb zone - Deborah, any idea what those regions are?);

	2) selecting a nearby city from a combo box (you can either select an item or type a name; it appears to do a fuzzy search of some sort when you type a name - "Cowabunga" found Cwmbran in the UK - but it has a limited number of cities, so "Weed" found Weert in the Netherlands rather than Weed in California).

It displays the *current* localized time zone name (so it distinguishes between standard and daylight savings/summer time), but doesn't distinguish between different tzdb regions that use "Mountain Time" - if daylight savings time isn't in effect, selecting Phoenix or Denver will both report the localized version of "Mountain Standard Time".

The iOS selector lacks the fancy GUI part; it just lets you enter a city name and search (and fails to find anything for "Weed").

Both OSes also offer the option of letting the machine select the zone automatically based on its location.

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

The Apple selectors don't work on zones, they work on cities.