Internationalization: Support for IANA time zones

Phillips, Addison addison at lab126.com
Fri Mar 1 09:41:18 PST 2013


Hello Norbert,

This looks good to me.

Regarding: 

> 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.

I think the least surprise would result if the GMT+/- string were used when no local representation is available. While the actually time zone is more specific, most callers are just trying to put a date or time value into their output for human consumption. In most cases, the DST transition rules are unimportant to a specific date value being rendered and the GMT offset is at least somewhat compact. Users are probably more familiar with this presentation and certainly will be happier with it than "America/Los_Angeles".

Addison

> -----Original Message-----
> From: Norbert Lindenberg [mailto:ecmascript at lindenbergsoftware.com]
> 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/


More information about the es-discuss mailing list