I must not be making the situation clear. The internal code is invariant across locales. But the "display name" for that code will change dramatically. That is, the TZID will not change. But its representation to local users must; because they may not know English. For example, "Europe/London" will remain constant. But the "display name" for it will reflect the representations of London (or "British Time"), such as the following: "Londain": ·ga· "Londen": ·nl· "London": ·da· ·en· ·fr· ·sv· "Londra": ·it· "Londres": ·es· ·pt· "Lontoo": ·fi· "ロンドン": ·ja· "伦敦": ·zh· "倫敦": ·zh_Hant· "런던": ·ko· Expecting otherwise is like expecting you to recognize 倫敦 as the name of a TZID. Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Guy Harris" <guy@alum.mit.edu> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: "Masayoshi Okutsu" <Masayoshi.Okutsu@sun.com>; <tz@lecserver.nci.nih.gov> Sent: Sun, 2004 Jun 13 20:14 Subject: Re: Time Zone Localizations
On Sat, Jun 12, 2004 at 09:24:34AM -0700, Mark Davis wrote:
I think we may be talking past one another. LDML provide for a way to *localize* the Olson TZIDs. For example, you can localize the term "Asia/Singapore".
Actually, "Asia/Singapore" is, in the Olson code, a relative pathname, so, in all locales, it's "Asia/Singapore" - i.e., the localization function is a no-op.
You might want to localize a textual description of that region, but that's a different matter.