From: Mark Davis (mark.davis@jtcsv.com)
Date: Tue May 11 2004 - 15:40:13 CDT
As far as I'm concerned, timezone choice is completely orthogonal to locale
choice. And trying to guess from the region in the locale is very chancy. The
UIs I've seen just list the choices; they don't try to narrow it by country.
After all, I might be traveling, or living in a different country than my
language setting is for in my browser.
You can do a full order of timezones, very easily, using a lexicographic
ordering. To see whether timezone X is greater than timezone Y, walk back in
time over each of them. At the first point where the offsets differ, the one
with the greater offset is first. If they are the same throughout the database
period, they are equal. That ordering relationship can be used to sort the
timezones. This method will also group together all of the zones that are equal
back through time to a given point. For example, all the zones that are the same
back to 5 years ago will be clumped together.
That being said, the one piece of data that I wish the Olson database had was:
given two timezones X and Y that are identical in behavior over the last N
years, which is the 'preferable' choice to show in a UI? Of course, that is a
choice that might vary by locale.
With that information, and the ordering, for some time period (say 5 years), one
can present an ordered list of only distinct timezones over that period, and use
the 'preferable' one to represent any others; either that or have a 2nd level
menu or 'advanced' option to get all of them.
Mark
BTW, what is curious is that the way the US timezones work, even though Pacific
Time is listed as being -08:00, a *majority* of the year it is actually -07:00,
and same for the others with daylight savings time.
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄
----- Original Message -----
From: "Carl W. Brown" <cbrown@xnetinc.com>
To: "Unicode List" <unicode@unicode.org>
Sent: Tue, 2004 May 11 07:31
Subject: RE: TR35
> Peter,
>
> > >If I live in Guam I will probably be using an en_US locale.
> > However the "US" territory does not contain my time zone.
> > Probably the best solution for this problem is to add a category
> > of possessions to the territory information. This allows
> > applications to enumerate available time zones for not only the
> > country itself but also it possessions that might be using the locale.
> > >
> > >
> >
> > This issue is not limited to a country's possessions. Many expatriates
> > and traveling business people etc want to keep their (laptop)
> > computer's general locale settings as that of their home country (not
> > least because changing this often destabilises data) but need to set it
> > to the time zone in which they are temporarily resident. So time zones
> > should be kept independent of other locale information, especially
> > independent of such things as date and decimal point formats, and
> > preferred languages.
>
> The problem is that if you give users the option to pick time zone and use
> the Olson zones then you want to be able to limit the number of zones that
> most people pick to the most likely ones. The time zones for the country of
> the locale I am using are the most likely ones. In the case of Guam I
> suspect that more people use en_US as a locale than en_GU. I don't think
> that many people actually implement an en_GU locale.
>
> To me setting a time zone should probably start by selecting the time zone
> list:
>
> 1) Locale country (In most cases there is only one so there is not need for
> a second selection)
> 2) Country and related territories or possessions.
> 3) Time zones matching current system time.
> 4) Time zones within one hour of current system time.
> 5) All time zones in time order starting with current system time.
>
> To stay out of politics I would list Mainland China, Hong Kong, Singapore
> and Taiwan under each other. Pick one get 4. The Falklands would be listed
> und both Great Britain and Argentina.
>
> One good point about using Unicode we can now use script rather than code
> page or specify Taiwan for Traditional script even if the person is not in
> Taiwan or Hong Kong.
>
> Expats break the locale model anyway. The problem is that we use country as
> both a language modifier and a location. Thus a Brazilian community in the
> US can not pick pt_BR as a language and US as a territory.
>
> TR35 explicitly designates the country portion as a territory not a language
> variant. Should there be two different specifications both using the same
> ISO 3066-1 codes and in most cases they will be the same?
>
> Carl
>
>
>
>
This archive was generated by hypermail 2.1.5 : Tue May 11 2004 - 15:41:43 CDT