From: Carl W. Brown (email@example.com)
Date: Fri May 07 2004 - 11:44:48 CDT
> LDML does require the Olson IDs to identify time zones
> (as does Unix, Java, ICU,...). See the discussion in
I found a normalization problem with the IDs. For example you have both "Asia/Istanbul" and "Europe/Istanbul" which are different names for the same time zone. I believe that the best solution is to drop the region designation because the time zones that we need are specific to a unique country. Thus "Istanbul" under "TR" works just fine. I do not believe that we need the "Etc/..." or miscellaneous aliases.
This changes TR35 to:
<zone type="Los_Angeles" >
<standard>Pacific Standard Time</standard>
<daylight>Pacific Daylight Time</daylight>
It will then be part of the locale territory properties.
Problem number 2:
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.
Thus es_PR, en_PR, en_US, and es_US will all have access to the "Puerto_Rico" time zone without replicating data and denormalizing the database. The application can choose to include territories or not depending on its specific requirements.
I believe that the strength of the Unicode standard is in the fact that in addition to unifying code pages it also is a mechanism to support normalizing of data and specifications.
This archive was generated by hypermail 2.1.5 : Fri May 07 2004 - 18:45:26 CDT