The Internationalization API spec has recommendations for CLDR, but does not require its use. And while CLDR covers the major languages of planet Earth pretty well, there's a long tail of ~6000 languages that it doesn't cover, so we still have to consider what happens when a caller requests one of those.
Norbert On Mar 1, 2013, at 6:04 , Andrew Paprocki wrote: > Norbert, Are you planning on using the Unicode CLDR data? This data has the > localized exemplar cities for every IANA timezone in every locale. For > example, America/New_York in Russian: > > http://unicode.org/cldr/trac/browser/tags/release-22-1/common/main/ru.xml#L3906 > > We currently use the IANA data for actual datetime computation, but the CLDR > data is used for things such as display and conversion from Windows timezone > identifiers -> IANA timezone identifiers. > > -Andrew > > > On Thu, Feb 28, 2013 at 7:13 PM, Shawn Steele <[email protected]> > wrote: > For #5 I might prefer falling back to English or something. I don't think > UTC offset is a good idea because that doesn't really represent a Timezone > very well. (If a meeting gets moved to a following week, that offset might > change or be wrong) > > -Shawn > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Norbert Lindenberg > Sent: Thursday, February 28, 2013 3:36 PM > To: es-discuss > Subject: Internationalization: Support for IANA time zones > > I'm updating the ECMAScript Internationalization API spec to support the > names of the IANA Time Zone Database [1] in DateTimeFormat. I'd like to > highlight a few key points of my draft to see whether there are comments: > > 1) The supported names are the Link and Zone names of the IANA Time Zone > Database. Names are matched ASCII-case-insensitively. > > 2) These names are canonicalized to the corresponding Zone name in the casing > used in the IANA Time Zone Database. Etc/GMT and Etc/UTC are canonicalized to > UTC. (The subtle differences between GMT and UTC probably don't matter to > users of this API.) > > 3) Implementations must recognize all registered Zone and Link names, reject > strings that are not registered, and use best available current and > historical information about their offsets from UTC and their daylight saving > time rules in calculations. (This is different from language tags and > currency codes, where we accept strings that fit a general pattern without > requiring reference to the actual registry. The IANA Time Zone Database > doesn't specify a general pattern for time zone names, and accepting a string > for which UTC offset and DST rules aren't known can only lead to errors.) > > 4) If no time zone name is provided to the DateTimeFormat constructor, > DateTimeFormat.prototype.resolvedOptions returns the canonicalized Zone name > of the host environment's current time zone. (This potentially incompatible > change was pre-announced in a note in section 12.3.3.) > > 5) The set of combinations of time zone name and language tag for which > localized time zone names are available is implementation dependent. Where no > localized time zone name is available, the canonicalized name is used in > formatted output. > > The last one I'm not entirely comfortable with: IANA time zone names can be > long and unfamiliar (e.g., America/Indiana/Tell_City), and sometimes people > think the wrong representative city was selected (e.g., Shanghai rather than > Beijing for China). An alternative might be to prescribe formatting as an > offset from UTC. > > Comments? > > Norbert > > [1] http://www.iana.org/time-zones/ > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
