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" <[EMAIL PROTECTED]> To: "Unicode List" <[EMAIL PROTECTED]> 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 > > > > > > >