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
