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
