Internationalization: Support for IANA time zones

Andrew Paprocki andrew at
Fri Mar 1 06:04:31 PST 2013

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:

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.


On Thu, Feb 28, 2013 at 7:13 PM, Shawn Steele <Shawn.Steele at>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: es-discuss-bounces at [mailto:
> es-discuss-bounces at] 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]
> _______________________________________________
> es-discuss mailing list
> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list