[tz] Discussion in ECMA about tz identifiers in JavaScript

[Guy Harris]

On Mar 5, 2013, at 12:22 AM, Mark Davis ☕ <mark at 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_ecetrd227.pdf

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!")