Internationalization: Support for IANA time zones
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)
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:
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.
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 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:
- The set of combinations of time zone name and language tag for which localized time zone names are available is implementation dependent.
Mark plus.google.com/114199149796022210033 * * — Il meglio è l’inimico del bene — **
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
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
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
Can we work with iana to get the names stabilized?
Sent from my Windows Phone 8
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:
- 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 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:
- 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
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 though 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:
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 plus.google.com/114199149796022210033 * * — Il meglio è l’inimico del bene — **
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 plus.google.com/114199149796022210033 * * — Il meglio è l’inimico del bene — **
On Sat, Mar 2, 2013 at 5:11 AM, Mark Davis ☕ <mark at macchiato.com> 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.
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.
On Sat, Mar 2, 2013 at 5:11 PM, Shawn Steele <Shawn.Steele at microsoft.com>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 unicode.org/repos/cldr/tags/release-22-1/common/bcp47/timezone.xml such as in:
<type name="inccu" alias="Asia/Calcutta Asia/Kolkata" description="Kolkata, India"/>
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.
<zone type="Asia/Calcutta"> <exemplarCity>ኮልካታ</exemplarCity> </zone> ... <zone type="Asia/Calcutta"> <exemplarCity>Kolkata</exemplarCity> </zone> ... <zone type="Asia/Calcutta"> <exemplarCity>コルカタ</exemplarCity> </zone>
and so on. Note that these are all TZIDs.
The only long ID that CLDR adds is one to indicate an unknown/illegal TZID:
<zone type="Etc/Unknown"> <exemplarCity>地域不明</exemplarCity> </zone>
Is the picture clearer now?
Mark plus.google.com/114199149796022210033 * * — Il meglio è l’inimico del bene — **
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: ecma-international.org/ecma-262/5.1/#sec-15.9.6, 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
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/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 unicode.org/repos/cldr/tags/release-22-1/common/bcp47/timezone.xml such as in:
<type name="inccu" alias="Asia/Calcutta Asia/Kolkata" description="Kolkata, India"/>
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
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
On Mar 2, 2013, at 10:34 AM, Norbert Lindenberg <ecmascript at lindenbergsoftware.com> 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: ecma-international.org/ecma-262/5.1/#sec-15.9.6, 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 at mozilla.org, mail.mozilla.org/listinfo/es-discuss
Jon Adams Sent from my Refrigerator
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
Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N WG)
Internationalization is not a feature. It is an architecture.
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 :)
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.
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
Zone Asia/Kolkata 5:53:28 - LMT 1880 # Kolkata ...
backward Link Asia/Kolkata Asia/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 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?
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: 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(1293868800000)) }
* ]
* 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(1320568200000)) }
* { offset: -28800, abbr: "PST", date: (new Date(1320571800000)) }
* ]
* 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
};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
Zone Asia/Kolkata 5:53:28 - LMT 1880 # Kolkata ...
backward Link Asia/Kolkata Asia/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 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. mm.icann.org/pipermail/tz/2013-March/018714.html
Norbert
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:
The supported names are the Link and Zone names of the IANA Time Zone Database. Names are matched ASCII-case-insensitively.
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.)
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.)
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.)
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] www.iana.org/time-zones