From: Carl W. Brown (email@example.com)
Date: Tue May 11 2004 - 09:31:15 CDT
> >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
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?
This archive was generated by hypermail 2.1.5 : Tue May 11 2004 - 09:32:30 CDT