These are zone IDs, so I'd rather want to keep them unchanged. I think there are some applications which store the zone IDs in persistent data. In these applications, any changes in zond IDs will require mapping table for backward compatibility support. Anyway, I'd like to address that these zone IDs are captured in the Common Locale Data Repository ( http://www.unicode.org/cldr/ ) and these region names are localized (timezones - exemplarCity... of course these localized names are represented by Unicode!). The latest version of CLDR includes local names, for example, "Montreal" in French locale is "Montréal". At this moment, the coverage of localization is not great, but it is improving in every CLDR releases. In my opinion, zone IDs should be stable and based on common English spelling and supporting native/localized city names via separated bundles such as CLDR timezones data. - Yoshito Umaoka (ICU project) "Paul Schauble" <Paul.Schauble@ticketmaster.com> wrote on 05/30/2007 06:45:53 PM:
-----Original Message----- From: Paul Koning [mailto:pkoning@equallogic.com] Sent: Wednesday, May 30, 2007 2:55 PM To: tz@lecserver.nci.nih.gov Cc: tz@lecserver.nci.nih.gov Subject: RE: zone.tab corrections
"Paul" == Paul Schauble <Paul.Schauble@ticketmaster.com> writes:
Paul> You could bite the bullet (US idion) and redefine the zone Paul> tables to be UTF-8.
Paul> I'm half kidding (I have Unicode very much on the brain right Paul> now). But I'm sure that will happen sooner or later.
Yes, that would be good in some ways. Not so good in other ways. It would be a hassle for travelers who are not sufficiently fluent in the local language to read the local place names in their specific script.
It also doesn't help the multiple official languages case, though you could cure that by putting multiple entries, one per language.
Paul
----------------------------------
Yes, exactly. Have one synonym for each local name. Just require that the English choice always exists.
++PLS