Re: Internationalization: Support for IANA time zones

[Norbert Lindenberg]

On Mar 4, 2013, at 22:49 , L. David Baron wrote:

> On Saturday 2013-03-02 10:50 -0800, Norbert Lindenberg wrote:
>> On Mar 2, 2013, at 8:46 , Mark Davis ? wrote:
>>> The TZDB has the equivalence class {Asia/Calcutta Asia/Kolkata}. They used 
>>> to have the former as the canonical name (in Zone), but then changed it to 
>>> the latter. Here is the current TZDB data:
>>> 
>>> zone.tab
>>> 
>>> IN  +2232+08822 Asia/Kolkata
>>> 
>>> asia
>>> 
>>> ZoneAsia/Kolkata5:53:28 -   LMT 1880# Kolkata
>>> ...
>>> 
>>> backward
>>> LinkAsia/KolkataAsia/Calcutta
>>> 
>>> Because of the Link, both are valid and equivalent.
> 
>> That breaks if/when the tz database removes Asia/Calcutta from its Link list 
>> and other systems using IANA names stop supporting (or never start 
>> supporting) that name.
>> 
>> I still think the stability issue should be addressed in the IANA time zone 
>> database itself, not by adopting a IANA-derived alternate registry. Has that 
>> been tried?
> 
> In http://mm.icann.org/pipermail/tz/2013-March/018697.html the
> maintainer of the timezone database wrote (in reference to this
> discussion):
>  # That discussion seems to be predicated on the assumption that
>  # tz zone names can and do "disappear", but they don't.  For example,
>  # we renamed Asia/Calcutta to Asia/Kolkata, but kept the old name
>  # as an alias for the new one.
> 
> So I think from their end, the "stability issue" is considered
> addressed.  Is that not sufficient?

Depends on how explicit that stability guarantee is. In the meantime I learned 
from the ongoing discussion that there is a Theory file, tucked away in the 
tzcode tar ball, that includes some rules. I proposed making that information a 
bit more prominent, e.g., in the form of an RFC.
http://mm.icann.org/pipermail/tz/2013-March/018714.html

Norbert

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[L. David Baron]

On Saturday 2013-03-02 10:34 -0800, Norbert Lindenberg wrote:
> I think a better solution would be API that either lets you easily
> generate a series of Date instances representing midnight (of
> every day, of every Monday, of every first day of the month, ...)
> in a specified time zone and calendar, or that lets you convert a
> Date to field-based time information in a specified time zone and
> calendar so that you can apply your own criteria.

The first of these is insufficient around daylight-savings time
cases for some uses, since it doesn't tell you when in the day the
time change is.

I think the second is also somewhat difficult to work with unless
one of the fields in question is a UTC offset; I believe (though I
admit I haven't written a large amount of timezone handling code).
It's often useful to work with epoch-based times and UTC offsets
rather than field-based times.

In my library that packed the tz database into JSON (one of many, it
sounds like), the API that I exposed was the following, quoting:
https://github.com/dbaron/tz.js/blob/3489978e9422c49f1bb4aafdfeee429a3e665136/tz.js.in#L191

// Exports:
window.tz = {
/**
 * zoneAt(zone, dateObj)
 *   Given a valid named time zone and a JavaScript date object,
 *   return a zone object with two properties:
 * offset: the UTC offset for the zone, in seconds
 * abbr: the correct short name for the zone
 * For example,
 *   tz.zoneAt("America/Los_Angeles",
 * new Date(Date.UTC(1976,6,4,18,0,0)))
 * (the time there is 1976-07-04 18:00:00 UTC) should return
 * an object like this:
 *   { offset: -25200, abbr: "PDT" }
 * since the America/Los_Angeles time zone observed summer time
 * at the time given, and was thus at offset UTC minus 7 hours
 * (or 25200 seconds), and used the abbreviation PDT (for
 * Pacific Daylight Time).
 */
zoneAt: public_zoneAt,

/**
 * datesFor(zone, year, month, day, hour, minute, second)
 *   Given a valid named time zone and a local time with:
 * year >= 1970 (but not on January 1)
 * month 1-12
 * day 1-31
 * hour 0-23
 * minute 0-59
 * second 0-59
 * returns an *array* of objects with three properties, the two
 * described above for zoneAt, and then a "date" property with a
 * JavaScript date object.  This array may have 0, 1, or 2
 * elements (and in theory it may have more in the future,
 * though the current code never produces such results).
 *
 * For example,
 *   tz.datesFor("America/Los_Angeles", 2011, 1, 1, 0, 0, 0)
 * will produce one result:
 * [
 *   { offset: -28800, abbr: "PST", date: (new Date(129386880)) }
 * ]
 * representing the moment of the new year 2011 in Los Angeles.
 * This is the common case.
 *
 * However, around summer time changes zero or two results can
 * occur.  For example:
 *   tz.datesFor("America/Los_Angeles", 2011, 3, 13, 2, 30, 0)
 * will produce an empty array since the start of summer time
 * causes the clock to jump from 2011-03-13 01:59:59 PST to
 * 2011-03-13 03:00:00 PDT.
 *
 * But this example:
 *   tz.datesFor("America/Los_Angeles", 2011, 11, 6, 1, 30, 0)
 * will produce two results:
 * [
 *   { offset: -25200, abbr: "PDT", date: (new Date(132056820)) }
 *   { offset: -28800, abbr: "PST", date: (new Date(132057180)) }
 * ]
 * representing times one hour apart, since the summer time
 * change makes the clock jump from 2011-11-06 01:59:59 PDT to
 * 2011-11-06 01:00:00 PST, and thus it passes 01:30 twice that
 * day.
 */
datesFor: public_datesFor,

/**
 * Return an array listing all supported named time zones, in
 * alphabetical order.  The same array will be returned from
 * each call.
 */
allZones: public_allZones
};

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla   http://www.mozilla.org/   𝄂
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[L. David Baron]

On Saturday 2013-03-02 10:50 -0800, Norbert Lindenberg wrote:
> On Mar 2, 2013, at 8:46 , Mark Davis ? wrote:
> > The TZDB has the equivalence class {Asia/Calcutta Asia/Kolkata}. They used 
> > to have the former as the canonical name (in Zone), but then changed it to 
> > the latter. Here is the current TZDB data:
> > 
> > zone.tab
> > 
> > IN  +2232+08822 Asia/Kolkata
> > 
> > asia
> > 
> > ZoneAsia/Kolkata5:53:28 -   LMT 1880# Kolkata
> > ...
> > 
> > backward
> > LinkAsia/KolkataAsia/Calcutta
> > 
> > Because of the Link, both are valid and equivalent.

> That breaks if/when the tz database removes Asia/Calcutta from its Link list 
> and other systems using IANA names stop supporting (or never start 
> supporting) that name.
> 
> I still think the stability issue should be addressed in the IANA time zone 
> database itself, not by adopting a IANA-derived alternate registry. Has that 
> been tried?

In http://mm.icann.org/pipermail/tz/2013-March/018697.html the
maintainer of the timezone database wrote (in reference to this
discussion):
  # That discussion seems to be predicated on the assumption that
  # tz zone names can and do "disappear", but they don't.  For example,
  # we renamed Asia/Calcutta to Asia/Kolkata, but kept the old name
  # as an alias for the new one.

So I think from their end, the "stability issue" is considered
addressed.  Is that not sufficient?

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla   http://www.mozilla.org/   𝄂
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Internationalization: Support for IANA time zones

[Shawn Steele]

> I still think the stability issue should be addressed in the IANA time zone 
> database itself, not by adopting a IANA-derived alternate registry. Has that 
> been tried?

I agree, we should be chatting with the IANA folks.

-Shawn


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Internationalization: Support for IANA time zones

[Shawn Steele]

My proposed fallback was the English name.  Granted that isn't always very 
readable, however my point was that using UTC-XX isn't just potentially hard to 
read, but it's also wrong.

I don't mind standardizing the fallback behavior, or recommending fallback 
behavior, I don't want misleading fallback though :)

-Shawn

-Original Message-
From: Norbert Lindenberg [mailto:ecmascr...@lindenbergsoftware.com] 
Sent: Saturday, March 2, 2013 11:09 AM
To: Shawn Steele
Cc: Norbert Lindenberg; Dean Landolt; Mark Davis ☕; Eric Albright; es-discuss; 
Phillips, Addison
Subject: Re: Internationalization: Support for IANA time zones


On Mar 2, 2013, at 8:11 , Shawn Steele wrote:

> Re: UTC vs Tz names
>  
> Sometimes UTC might be “enough”, or “almost enough”, but there’s a big 
> difference between Pacific Time and UTC-8, because sometimes it might be 
> UTC-7.  So just using UTC doesn’t really help formatting (people want 
> something they’re familiar with), and it doesn’t really solve describing the 
> TZ, because at a different time of the year that offset might be different.

Agreed, and if Microsoft or any other implementer wants to provide meaningful 
localized descriptions of all time zones in all languages, the spec certainly 
does not prevent that. The question was only whether the spec should describe a 
fallback to be used when an implementation doesn't have a meaningful localized 
description, and what that fallback should be.

Norbert

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Internationalization: Support for IANA time zones

[Phillips, Addison]

> >
> > The Date constructor and the functions creating Date instances may accept
> values expressed in the local time zone, but are all specified to calculate a 
> time
> value in UTC, which then gets stored in the [[PrimitiveValue]].
> 
> To speak to Dean's implications, many of the Date methods operate on the
> [[PrimitiveValue]] adjusted for an environmental local offset. Unless 
> specifying
> obvious UTC versions (e.g. Date.getDay() vs Date.getUTCDay()
> 
> So, it'd not that the local tz is carried around so much that all these 
> methods
> rely on the environments. No?

That’s correct, but those methods are also misleading and probably not 
something one would design for the Date class if designing it today. The 
proposal provides a better means for extracting calendar- and locale-specific 
field values from a Date object because it allows for calendar variation, local 
rule variation (start of week, week number, etc.), and for the application of 
time zone (either explicitly or implicitly). The addition of time zones will 
allow developers to get not only client-local values, but also to specify a 
time zone, as many applications require.

FWIW, the W3C I18N WG maintains a Note about some of the issues of working with 
time zones on the Web [1] which I think is helpful when talking about this 
topic. If you go through the use cases (Norbert, by the way, contributed them 
to that document), you can see that adding a time zone value to a Date is 
insufficient for some cases and is overkill for others. 

I don't think that formally defining time zones would alter the behavior of the 
getXXX methods, but then the getXXX methods are not sufficient for what you 
(and I and others) want/need to do anyway.

> >
> >> A zone tag already exists, if implicitly, on Dates. What's the harm in 
> >> making
> it explicit -- exposing it as a unique symbol? It could be made writable, and 
> a
> registry of IANA timezones could be exposed as symbols.
> >
> > According to the spec, there is no zone tag. Adding it would make simple
> operations like comparing the time values of two Date instances a lot more
> complicated, so I doubt we'd want to do that.
> 
> I don't follow how this would make anything more/less complicated if
> comparison operated on the [[PrimitaveValue]]. Especially if everything just
> defaults to the way it works now (grab environment's local offset). However, I
> get not wanting to muck up existing API..

If a Date is simply a wrapper around an epochal-time value (what the document I 
mentioned calls an "incremental time"), then most time-based operations on the 
primitive value becomes straightforward (comparison, equality, assignment, 
etc.). The value has no "time zone" inherent in it, since it is the same time 
in UTC everywhere that time is measured. The time zone only matters when 
extracting calendric field values (day, month, hour, etc.) and, as noted just 
below, this works better when applied externally. Indeed, it allows the same 
Date object to be handled in multiple time zones simultaneously, without 
altering the value itself. It does mean that the time zone must be passed as a 
separate variable if the time zone is important to the operations that will be 
performed on time values.

> 
> >
> > I think a better solution would be API that either lets you easily generate 
> > a
> series of Date instances representing midnight (of every day, of every Monday,
> of every first day of the month, ...) in a specified time zone and calendar, 
> or
> that lets you convert a Date to field-based time information in a specified 
> time
> zone and calendar so that you can apply your own criteria.
> 
> Agree.
> >

Addison

[1] http://www.w3.org/TR/timezone/

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Jonathan Adams]

On Mar 2, 2013, at 10:34 AM, Norbert Lindenberg 
 wrote:

> 
> On Mar 2, 2013, at 7:27 , Dean Landolt wrote:
> 
>> I agree it doesn't make sense to solve this problem in the context of 
>> formatting, but there wouldn't be an issue if we had a way to set the zone 
>> of a Date. In another thread it was claimed that "A Date is intended to 
>> represent a specific instance in time, irrespective of time zone". But this 
>> isn't true at all -- a Date already carries around a timezone tag internally.
> 
> What makes you believe that? According to the specification, the only data a 
> Date instance has is the [[PrimitiveValue]] internal property, which is a 
> time value, the number of milliseconds since 01 January, 1970 UTC:
> http://ecma-international.org/ecma-262/5.1/#sec-15.9.6
> http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.1
> 
> The Date constructor and the functions creating Date instances may accept 
> values expressed in the local time zone, but are all specified to calculate a 
> time value in UTC, which then gets stored in the [[PrimitiveValue]].

To speak to Dean's implications, many of the Date methods operate on the 
[[PrimitiveValue]] adjusted for an environmental local offset. Unless 
specifying obvious UTC versions (e.g. Date.getDay() vs Date.getUTCDay()

So, it'd not that the local tz is carried around so much that all these methods 
rely on the environments. No?

> 
>> And if you believe there's no use case for changing a date's timezone, try 
>> partitioning a set of Dates by day (or week, month, year, etc.) using a day 
>> boundary in a timezone other the current locale's or Zulu. I've come up 
>> against this use case more than once, and The solution sucks. It involves 
>> shipping some subset of the tz db to the client, which is ridiculous -- 
>> especially because there's an easy fix...
> 
> That's a good use case, and you're right, it's currently not supported.
> 
>> A zone tag already exists, if implicitly, on Dates. What's the harm in 
>> making it explicit -- exposing it as a unique symbol? It could be made 
>> writable, and a registry of IANA timezones could be exposed as symbols.
> 
> According to the spec, there is no zone tag. Adding it would make simple 
> operations like comparing the time values of two Date instances a lot more 
> complicated, so I doubt we'd want to do that.

I don't follow how this would make anything more/less complicated if comparison 
operated on the [[PrimitaveValue]]. Especially if everything just defaults to 
the way it works now (grab environment's local offset). However, I get not 
wanting to muck up existing API..

> 
> I think a better solution would be API that either lets you easily generate a 
> series of Date instances representing midnight (of every day, of every 
> Monday, of every first day of the month, ...) in a specified time zone and 
> calendar, or that lets you convert a Date to field-based time information in 
> a specified time zone and calendar so that you can apply your own criteria.

Agree. 
> 
> Norbert
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


Jon Adams
Sent from my Refrigerator
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Norbert Lindenberg]

On Mar 2, 2013, at 8:11 , Shawn Steele wrote:

> Re: UTC vs Tz names
>  
> Sometimes UTC might be “enough”, or “almost enough”, but there’s a big 
> difference between Pacific Time and UTC-8, because sometimes it might be 
> UTC-7.  So just using UTC doesn’t really help formatting (people want 
> something they’re familiar with), and it doesn’t really solve describing the 
> TZ, because at a different time of the year that offset might be different.

Agreed, and if Microsoft or any other implementer wants to provide meaningful 
localized descriptions of all time zones in all languages, the spec certainly 
does not prevent that. The question was only whether the spec should describe a 
fallback to be used when an implementation doesn't have a meaningful localized 
description, and what that fallback should be.

Norbert
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Norbert Lindenberg]

On Mar 2, 2013, at 8:46 , Mark Davis ☕ wrote:

> The TZDB has the equivalence class {Asia/Calcutta Asia/Kolkata}. They used to 
> have the former as the canonical name (in Zone), but then changed it to the 
> latter. Here is the current TZDB data:
> 
> zone.tab
> 
> IN+2232+08822 Asia/Kolkata
> 
> asia
> 
> Zone  Asia/Kolkata5:53:28 -   LMT 1880# Kolkata
> ...
> 
> backward
> Link  Asia/KolkataAsia/Calcutta
> 
> Because of the Link, both are valid and equivalent.
> 
> 
> CLDR, because we need stability, retains the former TZID as the canonical 
> name. That is the meaning of the first alias in 
> http://unicode.org/repos/cldr/tags/release-22-1/common/bcp47/timezone.xml 
> such as in:
> 
> 
> 
> The short name (name="...") is only used for BCP47 subtags (because of the 
> ASCII/8-char limit), not for communicating with TZDB implementations. Nor is 
> it used in CLDR for the canonical ID. 
> 
> Instead Asia/Calcutta is used as the canonical ID.

That breaks if/when the tz database removes Asia/Calcutta from its Link list 
and other systems using IANA names stop supporting (or never start supporting) 
that name.

I still think the stability issue should be addressed in the IANA time zone 
database itself, not by adopting a IANA-derived alternate registry. Has that 
been tried?

Norbert

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Norbert Lindenberg]

On Mar 2, 2013, at 7:27 , Dean Landolt wrote:

> I agree it doesn't make sense to solve this problem in the context of 
> formatting, but there wouldn't be an issue if we had a way to set the zone of 
> a Date. In another thread it was claimed that "A Date is intended to 
> represent a specific instance in time, irrespective of time zone". But this 
> isn't true at all -- a Date already carries around a timezone tag internally.

What makes you believe that? According to the specification, the only data a 
Date instance has is the [[PrimitiveValue]] internal property, which is a time 
value, the number of milliseconds since 01 January, 1970 UTC:
http://ecma-international.org/ecma-262/5.1/#sec-15.9.6
http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.1

The Date constructor and the functions creating Date instances may accept 
values expressed in the local time zone, but are all specified to calculate a 
time value in UTC, which then gets stored in the [[PrimitiveValue]].

> And if you believe there's no use case for changing a date's timezone, try 
> partitioning a set of Dates by day (or week, month, year, etc.) using a day 
> boundary in a timezone other the current locale's or Zulu. I've come up 
> against this use case more than once, and The solution sucks. It involves 
> shipping some subset of the tz db to the client, which is ridiculous -- 
> especially because there's an easy fix...

That's a good use case, and you're right, it's currently not supported.

> A zone tag already exists, if implicitly, on Dates. What's the harm in making 
> it explicit -- exposing it as a unique symbol? It could be made writable, and 
> a registry of IANA timezones could be exposed as symbols.

According to the spec, there is no zone tag. Adding it would make simple 
operations like comparing the time values of two Date instances a lot more 
complicated, so I doubt we'd want to do that.

I think a better solution would be API that either lets you easily generate a 
series of Date instances representing midnight (of every day, of every Monday, 
of every first day of the month, ...) in a specified time zone and calendar, or 
that lets you convert a Date to field-based time information in a specified 
time zone and calendar so that you can apply your own criteria.

Norbert
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Mark Davis ☕]

On Sat, Mar 2, 2013 at 5:11 PM, Shawn Steele wrote:

> I’m uncomfortable using the CLDR names, although perhaps they could be
> aliases, because other standards use the tzdb names and we have to be able
> to look up the tzdb names.  It might be nice to get more stability for the
> tzdb names, like aliases or something.
>
>
​I'm simply not explaining myself correctly. *The CLDR IDs (long IDs) *ARE*
tzdb IDs.* Let me give you a specific case.

The TZDB has the equivalence class {Asia/Calcutta Asia/Kolkata}. They used
to have the former as the canonical name (in Zone), but then changed it to
the latter. Here is the current TZDB data:

zone.tab

IN +2232+08822 Asia/Kolkata


asia

Zone Asia/Kolkata 5:53:28 - LMT 1880 # Kolkata
...


backward

Link Asia/Kolkata Asia/Calcutta


Because of the Link, both are valid and equivalent.


CLDR, because we need stability, retains the *former* TZID as the canonical
name. That is the meaning of the first alias in
http://unicode.org/repos/cldr/tags/release-22-1/common/bcp47/timezone.xml such
as in:



The short name (name="...") is only used for BCP47 subtags (because of the
ASCII/8-char limit), *not* for communicating with TZDB implementations. Nor
is it used in CLDR for the canonical ID.

Instead Asia/Calcutta is used as the canonical ID. Here are some of the
samples of the localizations.


ኮልካታ

...

Kolkata

...

コルカタ


and so on. Note that these are all TZIDs.

The only long ID that CLDR adds is one to indicate an unknown/illegal TZID:


地域不明



Is the picture clearer now?


Mark 
*
*
*— Il meglio è l’inimico del bene —*
**
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Internationalization: Support for IANA time zones

[Shawn Steele]

Re: CLDR names being “better” than tzdb names.

I’m uncomfortable using the CLDR names, although perhaps they could be aliases, 
because other standards use the tzdb names and we have to be able to look up 
the tzdb names.  It might be nice to get more stability for the tzdb names, 
like aliases or something.

Re: UTC vs Tz names

Sometimes UTC might be “enough”, or “almost enough”, but there’s a big 
difference between Pacific Time and UTC-8, because sometimes it might be UTC-7. 
 So just using UTC doesn’t really help formatting (people want something 
they’re familiar with), and it doesn’t really solve describing the TZ, because 
at a different time of the year that offset might be different.

-Shawn
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Dean Landolt]

On Sat, Mar 2, 2013 at 5:11 AM, Mark Davis ☕  wrote:

> > It seems we have agreement that the canonicalized IANA names are not
> good for formatted strings. I like the CLDR solution, but see it as
> implementation dependent. *Maybe there's just no value in trying to
> define something in the standard since any implementer can claim that
> "Center, North Dakota" and "GMT+09:00" are localized representations for
> some locale.* So, leave it all implementation dependent?
>
> ​I agree.​ (And you hit on an important point above.)
>


Maybe I'm missing something but ISTM there's an important difference
between "Center, North Dakota" and "+09:00" -- DST.

I agree it doesn't make sense to solve this problem in the context of
formatting, but there wouldn't be an issue if we had a way to set the zone
of a Date. In another thread it was claimed that "A Date is intended to
represent a specific instance in time, irrespective of time zone". But this
isn't true at all -- a Date already carries around a timezone tag
internally. And if you believe there's no use case for changing a date's
timezone, try partitioning a set of Dates by day (or week, month, year,
etc.) using a day boundary in a timezone other the current locale's or
Zulu. I've come up against this use case more than once, and The solution *
sucks*. It involves shipping some subset of the tz db to the client, which
is ridiculous -- especially because there's an easy fix...

A zone tag already exists, if implicitly, on Dates. What's the harm in
making it explicit -- exposing it as a unique symbol? It could be made
writable, and a registry of IANA timezones could be exposed as symbols. Per
the OP there we still need a mechanism to key the zone symbols -- I don't
understand this problem enough to say for sure but the mechanism Mark
described seems as good as any. As for how to query for a particular
exemplar city and what to do if not present -- this could be reduced to a
library problem.

This feature belongs in the language. It solves a real problem (as
evidenced by the libraries already built). But shipping all or part of the
Olsen db is madness -- the client already has it.



On Fri, Mar 1, 2013 at 10:33 PM, Norbert Lindenberg <
ecmascr...@lindenbergsoftware.com> wrote:

> And the time zone names in formatted output when no localized time zone
> name is available:
>
> On Feb 28, 2013, at 15:35 , Norbert Lindenberg wrote:
>
> > 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.
>
>
> On Feb 28, 2013, at 16:13 , Shawn Steele 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)
>
> On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote:
>
> > 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:
> >
> > 
> > Dumont d’Urville
> > 
> > 
> > Center, North Dakota
> > 
> >
> > 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.
>
> On Mar 1, 2013, at 9:41 , Phillips, Addison wrote:
>
> > 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".
>
> It seems we have agreement that the canonicalized IANA names are not good
> for formatted strings. I like the CLDR solution, but see it as
> implementation dependent. Maybe there's just no value in trying to define
> something in the standard since any implementer can claim that "Center,
> North Dakota" and "GMT+09:00" are localized representations for some
> locale. So, leave it all implementation dependent?
>
> Norbert
>
> __

Re: Internationalization: Support for IANA time zones

[Mark Davis ☕]

> It seems we have agreement that the canonicalized IANA names are not good
for formatted strings. I like the CLDR solution, but see it as
implementation dependent. *Maybe there's just no value in trying to define
something in the standard since any implementer can claim that "Center,
North Dakota" and "GMT+09:00" are localized representations for some locale.
* So, leave it all implementation dependent?

​I agree.​ (And you hit on an important point above.)



Mark 
*
*
*— Il meglio è l’inimico del bene —*
**


On Fri, Mar 1, 2013 at 10:33 PM, Norbert Lindenberg <
ecmascr...@lindenbergsoftware.com> wrote:

> And the time zone names in formatted output when no localized time zone
> name is available:
>
> On Feb 28, 2013, at 15:35 , Norbert Lindenberg wrote:
>
> > 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.
>
>
> On Feb 28, 2013, at 16:13 , Shawn Steele 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)
>
> On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote:
>
> > 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:
> >
> > 
> > Dumont d’Urville
> > 
> > 
> > Center, North Dakota
> > 
> >
> > 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.
>
> On Mar 1, 2013, at 9:41 , Phillips, Addison wrote:
>
> > 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".
>
> It seems we have agreement that the canonicalized IANA names are not good
> for formatted strings. I like the CLDR solution, but see it as
> implementation dependent. Maybe there's just no value in trying to define
> something in the standard since any implementer can claim that "Center,
> North Dakota" and "GMT+09:00" are localized representations for some
> locale. So, leave it all implementation dependent?
>
> Norbert
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Mark Davis ☕]

T
​here are two different issues:

Zone - what we do in CLDR solves the issue. All implementations should, and
as far as I know, do, accept all of the valid TZIDs. Because we use
existing valid TZIDs as the canonical form, even tho​ugh they are not the
same as in the Zone file, it all works. And we in EcmaScript can reference
the CLDR IDs without requiring the use of any of the localization data;
they are maintained in the timezone.xml file, eg:

http://unicode.org/repos/cldr/tags/release-22-1/common/bcp47/timezone.xml

We have also developed and maintain the short unique IDs that you see
there, so that the Olson TZIDs can be used in locale tags.


Disappearing IDs. Yes, the best that can be done for that is to keep any
old ones despite what the IANA registry does, and deprecate them. That's
also what we do in BCP47 with disappearing ISO codes (ugg). The downside
here is that a different implementation of the IANA timezone APIs may drop
support for the old ones. So we have to decide whether that is a
requirement of implementations or not.


Mark 
*
*
*— Il meglio è l’inimico del bene —*
**


On Fri, Mar 1, 2013 at 9:40 PM, Norbert Lindenberg <
ecmascr...@lindenbergsoftware.com> wrote:

> The identifier issues first:
>
> On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote:
>
> > > 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.
>
> The lack of stability in these identifiers is a problem. I don't see
> however how creating our own set (or using a set defined by CLDR) would
> help with interoperability with other systems based on IANA time zone
> names. It reminds me of how the Java Locale class was specified in 1997 to
> use language codes for three languages that ISO had deprecated years
> earlier, forcing Java developers to deal with an incompatibility between
> the Java world (including down to the file names of resource bundles) and
> the rest of the world.
>
> Has anybody tried to correct this at the source, by writing an RFC with
> maintenance rules for the names in the time zone database, similar to
> what's in BCP 47? How did the folks on the tz mailing list react?
>
> > > reject strings that are not registered
> >
> > That is another problem, since the TZ database does not guarantee
> non-removal (and has removed IDs).
>
> This one could be corrected by allowing as input all names that were in
> the time zone database at any time after a given date, e.g. after IANA took
> over, and treating them as Link names.
>
> Norbert
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Norbert Lindenberg]

And the time zone names in formatted output when no localized time zone name is 
available:

On Feb 28, 2013, at 15:35 , Norbert Lindenberg wrote:

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


On Feb 28, 2013, at 16:13 , Shawn Steele 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)

On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote:

> 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:
> 
> 
> Dumont d’Urville
> 
> 
> Center, North Dakota
> 
> 
> 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.

On Mar 1, 2013, at 9:41 , Phillips, Addison wrote:

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

It seems we have agreement that the canonicalized IANA names are not good for 
formatted strings. I like the CLDR solution, but see it as implementation 
dependent. Maybe there's just no value in trying to define something in the 
standard since any implementer can claim that "Center, North Dakota" and 
"GMT+09:00" are localized representations for some locale. So, leave it all 
implementation dependent?

Norbert

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Internationalization: Support for IANA time zones

[Shawn Steele]

Can we work with iana to get the names stabilized?

Sent from my Windows Phone 8

From: Norbert Lindenberg<mailto:ecmascr...@lindenbergsoftware.com>
Sent: ‎3/‎1/‎2013 12:41 PM
To: Mark Davis ☕<mailto:m...@macchiato.com>
Cc: Shawn Steele<mailto:shawn.ste...@microsoft.com>; 
es-discuss<mailto:es-discuss@mozilla.org>
Subject: Re: Internationalization: Support for IANA time zones

The identifier issues first:

On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote:

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

The lack of stability in these identifiers is a problem. I don't see however 
how creating our own set (or using a set defined by CLDR) would help with 
interoperability with other systems based on IANA time zone names. It reminds 
me of how the Java Locale class was specified in 1997 to use language codes for 
three languages that ISO had deprecated years earlier, forcing Java developers 
to deal with an incompatibility between the Java world (including down to the 
file names of resource bundles) and the rest of the world.

Has anybody tried to correct this at the source, by writing an RFC with 
maintenance rules for the names in the time zone database, similar to what's in 
BCP 47? How did the folks on the tz mailing list react?

> > reject strings that are not registered
>
> That is another problem, since the TZ database does not guarantee non-removal 
> (and has removed IDs).

This one could be corrected by allowing as input all names that were in the 
time zone database at any time after a given date, e.g. after IANA took over, 
and treating them as Link names.

Norbert
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Norbert Lindenberg]

The identifier issues first:

On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote:

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

The lack of stability in these identifiers is a problem. I don't see however 
how creating our own set (or using a set defined by CLDR) would help with 
interoperability with other systems based on IANA time zone names. It reminds 
me of how the Java Locale class was specified in 1997 to use language codes for 
three languages that ISO had deprecated years earlier, forcing Java developers 
to deal with an incompatibility between the Java world (including down to the 
file names of resource bundles) and the rest of the world.

Has anybody tried to correct this at the source, by writing an RFC with 
maintenance rules for the names in the time zone database, similar to what's in 
BCP 47? How did the folks on the tz mailing list react?

> > reject strings that are not registered
> 
> That is another problem, since the TZ database does not guarantee non-removal 
> (and has removed IDs).

This one could be corrected by allowing as input all names that were in the 
time zone database at any time after a given date, e.g. after IANA took over, 
and treating them as Link names.

Norbert
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Internationalization: Support for IANA time zones

[Phillips, Addison]

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:ecmascr...@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/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Norbert Lindenberg]

The Internationalization API spec has recommendations for CLDR, but does not 
require its use. And while CLDR covers the major languages of planet Earth 
pretty well, there's a long tail of ~6000 languages that it doesn't cover, so 
we still have to consider what happens when a caller requests one of those.

Norbert


On Mar 1, 2013, at 6:04 , Andrew Paprocki 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  
> 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-boun...@mozilla.org [mailto:es-discuss-boun...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Mark Davis ☕]

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


Dumont d’Urville


Center, North Dakota


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 
*
*
*— Il meglio è l’inimico del bene —*
**


On Fri, Mar 1, 2013 at 3:04 PM, Andrew Paprocki  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 
> 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-boun...@mozilla.org [mailto:
>> es-discuss-boun...@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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _

Re: Internationalization: Support for IANA time zones

[Andrew Paprocki]

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 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-boun...@mozilla.org [mailto:
> es-discuss-boun...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Internationalization: Support for IANA time zones

[Shawn Steele]

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-boun...@mozilla.org [mailto:es-discuss-boun...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss