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
