Discussion in ECMA about tz identifiers in JavaScript
In case anyone’s interested, there’s a discussion on es-discuss@mozilla.org<mailto:es-discuss@mozilla.org> (the ecmascript discussion list) about time zone identifiers in Javascript. -Shawn http://blogs.msdn.com/shawnste
On Mar 4, 2013, at 9:45 AM, Shawn Steele <Shawn.Steele@microsoft.com> wrote:
In case anyone’s interested, there’s a discussion on es-discuss@mozilla.org (the ecmascript discussion list) about time zone identifiers in Javascript.
In case anyone's interested, here's the page at mozilla.org for that mailing list: https://mail.mozilla.org/listinfo/es-discuss
From looking at the "Internationalization: Support for IANA time zones" thread in the March 2013 archives, one issue they have is that time zone IDs can disappear. Asia/Calcutta -> Asia/Kolkata appears to be one example.
Another issue mentioned at least in passing is the old "surprising choice of city name" issue. As per an earlier suggestion I may have made, should we pick a bunch of numerical identifiers for all zones, make *those* the official zone IDs, leave the old names behind as aliases, and thus avoid having to worry about 1) people complaining we picked the "wrong" city for the zone name; 2) the "right" city changing due to population changes; 3) a city's name or name spelling changing; etc.. This is at most a half-humorous suggestion. Alphanumeric might be an alternative, as long as we don't end up using the letters for something that sounds like a city name.
should we pick a bunch of numerical identifiers for all zones...
We could use (a variant of) the latitude/longitude coordinates in zone.tab, although we might then get complaints about using the "wrong" coordinates. @dashdashado On Mon, Mar 4, 2013 at 2:06 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Mar 4, 2013, at 9:45 AM, Shawn Steele <Shawn.Steele@microsoft.com> wrote:
In case anyone’s interested, there’s a discussion on es-discuss@mozilla.org (the ecmascript discussion list) about time zone identifiers in Javascript.
In case anyone's interested, here's the page at mozilla.org for that mailing list:
https://mail.mozilla.org/listinfo/es-discuss
From looking at the "Internationalization: Support for IANA time zones" thread in the March 2013 archives, one issue they have is that time zone IDs can disappear. Asia/Calcutta -> Asia/Kolkata appears to be one example.
Another issue mentioned at least in passing is the old "surprising choice of city name" issue.
As per an earlier suggestion I may have made, should we pick a bunch of numerical identifiers for all zones, make *those* the official zone IDs, leave the old names behind as aliases, and thus avoid having to worry about
1) people complaining we picked the "wrong" city for the zone name;
2) the "right" city changing due to population changes;
3) a city's name or name spelling changing;
etc..
This is at most a half-humorous suggestion.
Alphanumeric might be an alternative, as long as we don't end up using the letters for something that sounds like a city name.
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. I'm not sure it's worth my time to join that discussion (I am already on too many mailing lists) but you might want to forward this information.
On Mon, 04 Mar 2013, Paul Eggert wrote:
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.
Have any tz id's ever disappeared in the past? Even if they have, perhaps the tz project could guarantee that none will disappear in the future. --apb (Alan Barrett)
On 03/04/2013 11:07 PM, Alan Barrett wrote:
Have any tz id's ever disappeared in the past?
I don't recall any, no. My memory is not perfect.
perhaps the tz project could guarantee that none will disappear in the future.
I'm not sure what is meant by "guarantee", but it is listed as the last of the general rules used for location names, in the Theory file.
<<On Tue, 05 Mar 2013 00:37:57 -0800, Paul Eggert <eggert@cs.ucla.edu> said:
I'm not sure what is meant by "guarantee", but it is listed as the last of the general rules used for location names, in the Theory file.
Note that in FreeBSD, for example, we do not use the "backward" file (it's a bit too backward). -GAWollman
On Mar 5, 2013, at 0:37 , Paul Eggert wrote:
On 03/04/2013 11:07 PM, Alan Barrett wrote:
Have any tz id's ever disappeared in the past?
I don't recall any, no. My memory is not perfect.
perhaps the tz project could guarantee that none will disappear in the future.
I'm not sure what is meant by "guarantee", but it is listed as the last of the general rules used for location names, in the Theory file.
I wasn't aware of the Theory file, but found it after some digging. Would it be possible to put the content of the "Names of time zone rule files" section into a more prominent place? The best solution for external references to the time zone database would actually be an RFC containing that information - section 3 of RFC 6557 would have been a good place. Has that been considered before? I'm the editor of the ECMAScript Internationalization API Specification, and am adding time zone support for the second edition of that standard, hence my interest in this. Thanks, Norbert
As per an earlier suggestion I may have made, should we pick a bunch of numerical identifiers for all zones, make *those* the official zone IDs, leave the old names behind as aliases, and thus avoid having to worry about
For some years I've been running precisely that list, in a C enum, which is being used in an embedded environment (we store the numeric id in the embedded system's config which then writes it out into every data packet, along with a sensible UTC value; the desktop data display programs then display UTC and local time for wherever that embedded device happens to live). This was mentioned in an email many years ago but didn't garner any interest so I've not publicised it much since. However, it'd be really useful to me (!) if this list (and the enum, as example code) could become part of the tz distribution...
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.
Have any tz id's ever disappeared in the past? Even if they have, perhaps the tz project could guarantee that none will disappear in the future.
--apb (Alan Barrett)
I think that there *was* one zone that appeared, was deemed to be a mistake a few weeks later and then disappeared again, within the last couple of years; I'll have to check my records when I get home to verify this, but I certainly recall my validation routines throwing up errors about this. Regards, Stephen Goudge Engineer 390 Princesway Team Valley Gateshead Tyne & Wear NE11 0TU T +44 (0) 191 420 3015 F +44 (0) 191 420 3030 W www.petards.com This email has been sent from Petards Group plc or a member of the Petards group of companies. The information in this email is confidential and/or privileged. It is intended solely for the use of the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any review, dissemination, disclosure, alteration, printing, circulation or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful. Petards Group plc is registered in England & Wales. Company No. 2990100 Petards Limited is registered in England & Wales. Company No. 2301063 Petards Joyce-Loebl Limited is registered in England & Wales. Company No. 2170100 Registered Offices: 390 Princesway, Team Valley, Gateshead, Tyne & Wear NE11 0TU, UK. ___________________________________________________________________________________________ This email has been scanned by Petards. The service is powered by Symantec MessageLabs Email AntiVirus.cloud ___________________________________________________________________________________________
Have any tz id's ever disappeared in the past? Even if they have, perhaps the tz project could guarantee that none will disappear in the future.
--apb (Alan Barrett)
I think that there *was* one zone that appeared, was deemed to be a mistake a few weeks later and then >disappeared again, within the last couple of years; I'll have to check my records when I get home to verify this, >but I certainly recall my validation routines throwing up errors about this.
The entry I was thinking of was Europe/Tiraspol, which appeared in tzdata2011m and was removed again in tzdata2011n - in the latter it was "replaced" by an alias (for Europe/Chisinau) so *most* uses of the tzdata would trundle along fine... Regards, Stephen Goudge Engineer 390 Princesway Team Valley Gateshead Tyne & Wear NE11 0TU T +44 (0) 191 420 3015 F +44 (0) 191 420 3030 W www.petards.com This email has been sent from Petards Group plc or a member of the Petards group of companies. The information in this email is confidential and/or privileged. It is intended solely for the use of the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any review, dissemination, disclosure, alteration, printing, circulation or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful. Petards Group plc is registered in England & Wales. Company No. 2990100 Petards Limited is registered in England & Wales. Company No. 2301063 Petards Joyce-Loebl Limited is registered in England & Wales. Company No. 2170100 Registered Offices: 390 Princesway, Team Valley, Gateshead, Tyne & Wear NE11 0TU, UK. This email has been sent from Petards Group plc or a member of the Petards group of companies. The information in this email is confidential and/or privileged. It is intended solely for the use of the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any review, dissemination, disclosure, alteration, printing, circulation or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful. Petards Group plc is registered in England & Wales. Company No. 2990100 Petards Limited is registered in England & Wales. Company No. 2301063 Petards Joyce-Loebl Limited is registered in England & Wales. Company No. 2170100 Registered Offices: 390 Princesway, Team Valley, Gateshead, Tyne & Wear NE11 0TU, UK. ___________________________________________________________________________________________ This email has been scanned by Petards. The service is powered by Symantec MessageLabs Email AntiVirus.cloud ___________________________________________________________________________________________
The main issue for CLDR and other clients like it is to be able to have completely stable canonical identifiers. The zone.tab doesn't quite work for that, because of changes like Asia/Kolkata. As far as CLDR is concerned, the TZIDs are purely internal identifiers, and it makes no difference whether one is spelled Calcutta or Kolkata; end users should never ever see those anyway. What is a great concern is maintaining stability of the identifiers, so that they are stable keys for translations and other related usage. That's why CLDR needs to keep its own list (not really wanting to). These use the zone.tab IDs, but are stabilized (eg, no changes in spelling). CLDR also adds one identifier "Etc/Unknown", which is used in circumstances where a field is required, but there is no valid, known TZID. Note: I was wrong about the removal of IDs: I was thinking of the removal of Timbuktu in 2006, but that was moved to the backward file. http://article.gmane.org/gmane.comp.time.tz/866/match=remove+1970 === Not germane to the above, but FYI: CLDR also adds BCP47-compatible stable short identifiers. BCP47 has the historical restriction of no more than 8 characters, and only ASCII letters and digits. The short identifiers use UN [LOCODE] 5-letter codes wherever possible. There are a few identifiers of length not equal to 5, used where there is no corresponding LOCODE, such as "usnavajo" for "America/Shiprock Navajo", or "utcw01" for "Etc/GMT+1". Example: <type name="inccu" alias="Asia/Calcutta Asia/Kolkata" description="Kolkata, India"/> There is one other (minor) issue with the identifiers. The TZDB separates zones by country in zone.tab, but it is missing the following BCP47 regions: Ascension Island [AC] Bouvet Island [BV] Clipperton Island [CP] Diego Garcia [DG] Ceuta and Melilla [EA] Heard Island and McDonald Islands [HM] Canary Islands [IC] Tristan da Cunha [TA] Some of these are simply rocks with no permanent inhabitants, but for testing completeness it is useful to have them. Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Mon, Mar 4, 2013 at 11:37 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
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.
I'm not sure it's worth my time to join that discussion (I am already on too many mailing lists) but you might want to forward this information.
On 03/05/2013 12:22 AM, Mark Davis ☕ wrote:
The main issue for CLDR and other clients like it is to be able to have completely stable canonical identifiers. The zone.tab doesn't quite work for that,
That's fine, but that's a different issue. Identifiers are not removed from the tz database. Occasionally zones are renamed, but the old names continue to work. If CLDR doesn't like the new names, it can continue to use the old names. Some of the discussion on the ECMA mailing list seems to be assuming that tz names can "disappear", or that the Zone names are "unstable", but this assumption is incorrect -- unless by "unstable" one means that names are sometimes *added* to the database.
If CLDR doesn't like the new names, > it can continue to use the old names .
It isn't that we don't "like" the new names, it's that we need the names (in zone.tab) not to change once defined. So we do exactly as you suggest, "continue to use the old names". Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Tue, Mar 5, 2013 at 9:49 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 03/05/2013 12:22 AM, Mark Davis ☕ wrote:
The main issue for CLDR and other clients like it is to be able to have completely stable canonical identifiers. The zone.tab doesn't quite work for that,
That's fine, but that's a different issue. Identifiers are not removed from the tz database. Occasionally zones are renamed, but the old names continue to work. If CLDR doesn't like the new names, it can continue to use the old names.
Some of the discussion on the ECMA mailing list seems to be assuming that tz names can "disappear", or that the Zone names are "unstable", but this assumption is incorrect -- unless by "unstable" one means that names are sometimes *added* to the database.
On Mar 5, 2013, at 12:22 AM, Mark Davis ☕ <mark@macchiato.com> wrote:
The main issue for CLDR and other clients like it is to be able to have completely stable canonical identifiers. The zone.tab doesn't quite work for that, because of changes like Asia/Kolkata. As far as CLDR is concerned, the TZIDs are purely internal identifiers, and it makes no difference whether one is spelled Calcutta or Kolkata
...or 72013.
Not germane to the above, but FYI:
CLDR also adds BCP47-compatible stable short identifiers. BCP47 has the historical restriction of no more than 8 characters, and only ASCII letters and digits.
And if it's what's identified by RFC 5646, that's entitled "Tags for Identifying Languages", not "Tags for Identifying Regions That Have The Same History Of Time Zone Offsets And Daylight Savings Time Rules". Presumably by "BCP47-compatible" you mean "using the same syntax as the one used for BCP 47 language identifiers"?
The short identifiers use UN [LOCODE] 5-letter codes wherever possible.
LOCODEs: http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec16/rec16_rev3_e... appear to be "a coded representation for the names of ports, airports, inland clearance depots, inland freight terminals and other transport related locations, such as places of receipt and delivery, which are used for goods movements associated with trade (for example locations where Customs clearance of goods can take place), or otherwise proposed by Governments". Presumably "wherever possible" means "where there is a port, airport, inland clearance depot, inland freight terminal, or other transport related location within the zone"? (That still has the risk of somebody getting peeved if you haven't chosen the "right" port, airport, inland clearance depot, island freight terminal, or other transport related location, although if the LOCODE doesn't too noisily mention the name of the city, *maybe* people won't say "dammit, it should be CN BJO, not CN SHA!")
Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Tue, Mar 5, 2013 at 10:12 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Mar 5, 2013, at 12:22 AM, Mark Davis ☕ <mark@macchiato.com> wrote:
The main issue for CLDR and other clients like it is to be able to have completely stable canonical identifiers. The zone.tab doesn't quite work for that, because of changes like Asia/Kolkata. As far as CLDR is concerned, the TZIDs are purely internal identifiers, and it makes no difference whether one is spelled Calcutta or Kolkata
...or 72013.
True.
Not germane to the above, but FYI:
CLDR also adds BCP47-compatible stable short identifiers. BCP47 has the historical restriction of no more than 8 characters, and only ASCII letters and digits.
And if it's what's identified by RFC 5646, that's entitled "Tags for Identifying Languages", not "Tags for Identifying Regions That Have The Same History Of Time Zone Offsets And Daylight Savings Time Rules".
It is not the latter of course. BCP47 stabilizes its codes (the source ISO standards not themselves being stable, having done dumb things like removing the code CS, then later using it to mean a *different* country). Because of that, it is the best standard to reference for region codes, including country codes.
Presumably by "BCP47-compatible" you mean "using the same syntax as the one used for BCP 47 language identifiers"?
The short identifiers use UN [LOCODE] 5-letter codes wherever possible.
LOCODEs:
http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec16/rec16_rev3_e...
appear to be "a coded representation for the names of ports, airports, inland clearance depots, inland freight terminals and other transport related locations, such as places of receipt and delivery, which are used for goods movements associated with trade (for example locations where Customs clearance of goods can take place), or otherwise proposed by Governments".
It also includes cities, which are what we use, so that we map directly to the TZID cities.
Presumably "wherever possible" means "where there is a port, airport, inland clearance depot, inland freight terminal, or other transport related location within the zone"? (That still has the risk of somebody getting peeved if you haven't chosen the "right" port, airport, inland clearance depot, island freight terminal, or other transport related location, although if the LOCODE doesn't too noisily mention the name of the city, *maybe* people won't say "dammit, it should be CN BJO, not CN SHA!")
Of course, people can complain about anything, whether they have good reason or not. But if the identifiers look more like codes and less like actual names that might appear in UIs, it reduces the pointless complaints.
participants (9)
-
Alan Barrett -
Arthur David Olson -
Garrett Wollman -
Goudge, Stephen -
Guy Harris -
Mark Davis ☕ -
Norbert Lindenberg -
Paul Eggert -
Shawn Steele