T here are two different issues: Zone - what we do in CLDR solves the issue. All implementations should, and as far as I know, do, accept all of the valid TZIDs. Because we use existing valid TZIDs as the canonical form, even though they are not the same as in the Zone file, it all works. And we in EcmaScript can reference the CLDR IDs without requiring the use of any of the localization data; they are maintained in the timezone.xml file, eg:
http://unicode.org/repos/cldr/tags/release-22-1/common/bcp47/timezone.xml We have also developed and maintain the short unique IDs that you see there, so that the Olson TZIDs can be used in locale tags. Disappearing IDs. Yes, the best that can be done for that is to keep any old ones despite what the IANA registry does, and deprecate them. That's also what we do in BCP47 with disappearing ISO codes (ugg). The downside here is that a different implementation of the IANA timezone APIs may drop support for the old ones. So we have to decide whether that is a requirement of implementations or not. Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Fri, Mar 1, 2013 at 9:40 PM, Norbert Lindenberg < [email protected]> wrote: > The identifier issues first: > > On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote: > > > > These names are canonicalized to the corresponding Zone name in the > casing used > > > > Because the Zone names are unstable, in CLDR we adopted the same > convention as in BCP47. That is, our canonical form never changes, no > matter what happens to Zone names. I'd strongly recommend using those as > the canonical names to prevent instabilities. > > The lack of stability in these identifiers is a problem. I don't see > however how creating our own set (or using a set defined by CLDR) would > help with interoperability with other systems based on IANA time zone > names. It reminds me of how the Java Locale class was specified in 1997 to > use language codes for three languages that ISO had deprecated years > earlier, forcing Java developers to deal with an incompatibility between > the Java world (including down to the file names of resource bundles) and > the rest of the world. > > Has anybody tried to correct this at the source, by writing an RFC with > maintenance rules for the names in the time zone database, similar to > what's in BCP 47? How did the folks on the tz mailing list react? > > > > reject strings that are not registered > > > > That is another problem, since the TZ database does not guarantee > non-removal (and has removed IDs). > > This one could be corrected by allowing as input all names that were in > the time zone database at any time after a given date, e.g. after IANA took > over, and treating them as Link names. > > Norbert
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
