Mark,
> LDML does require the Olson IDs to identify time zones
> (as does Unix, Java, ICU,...). See the discussion in
> http://www.unicode.org/reports/tr35/.
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" >
<long>
<generic>Pacific Time</generic>
<standard>Pacific Standard Time</standard>
<daylight>Pacific Daylight Time</daylight>
</long>
<short>
<generic>PT</generic>
<standard>PST</standard>
<daylight>PDT</daylight>
</short>
<exemplarCity>San Francisco</exemplarCity>
</zone>
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.
Carl
