From: Mark Davis (mark.davis@jtcsv.com)
Date: Fri May 07 2004 - 14:45:42 CDT
That is not a problem. The Olson IDs are not guaranteed to be unique, just
unambiguous. And there are aliases. Typically these are de-unified for political
purposes. Thus you may find that two different IDs produce the same results over
the entire period of time in the database.
Moreover, whether or not someone wants to consider two IDs as 'equivalent'
depends on their timeframe. If I only care about the last 5 years, then many
more IDs fall into the same equivalence class than if I look over the entire
period of time covered by Olson.
While I do not believe that the database is perfect, there is no need to invent
yet another mechanism.
Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄
----- Original Message -----
From: "Carl W. Brown" <cbrown@xnetinc.com>
To: "Unicode List" <unicode@unicode.org>
Sent: Fri, 2004 May 07 09:44
Subject: TR35 (was: Standardize TimeZone ID
> 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
>
>
>
>
>
>
>
This archive was generated by hypermail 2.1.5 : Fri May 07 2004 - 18:45:26 CDT