Internationalization: Support for IANA time zones

Andrew Paprocki andrew at ishiboo.com
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:

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 <Shawn.Steele at microsoft.com>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 mozilla.org [mailto:
> es-discuss-bounces at mozilla.org] 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130301/d2b802b8/attachment-0001.html>


More information about the es-discuss mailing list