Internationalization: Support for IANA time zones

Mark Davis ☕ mark at macchiato.com
Fri Mar 1 07:40:10 PST 2013


> These names are canonicalized to the corresponding Zone name in the
casing used

Because the Zone names are unstable, in CLDR we adopted the same convention
as in BCP47. That is, our canonical form never changes, no matter what
happens to Zone names. I'd strongly recommend using those as the canonical
names to prevent instabilities.

> reject strings that are not registered

That is another problem, since the TZ database does not guarantee
non-removal (and *has* removed IDs).

> Where no localized time zone name is available, the canonicalized name is
used in formatted output.
>  An alternative might be to prescribe formatting as an offset from UTC.

This is a problematic. The canonicalized names are very ugly. What we do in
CLDR is return the last label, after some modifications (in
http://www.unicode.org/repos/cldr/trunk/common/main/root.xml). We don't
want to return the raw IDs. I think this needs to be implementation
dependent.

For example:

<zone type="Antarctica/DumontDUrville">
<exemplarCity>Dumont d’Urville</exemplarCity>
</zone>
<zone type="America/North_Dakota/Center">
<exemplarCity>Center, North Dakota</exemplarCity>
</zone>

So I think we should just have #5 be:

5) The set of combinations of time zone name and language tag for which
localized time zone names are available is implementation dependent.


Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**


On Fri, Mar 1, 2013 at 3:04 PM, Andrew Paprocki <andrew at ishiboo.com> 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 <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
>>
>
>
> _______________________________________________
> 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/7ec99b2b/attachment.html>


More information about the es-discuss mailing list