[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search
 
Modify

CLDR Ticket #9133(accepted data)

Opened 20 months ago

Last modified 5 months ago

Review UN Locode 2015 for tz codes

Reported by: mark Owned by: yoshito
Component: timezone Data Locale:
Phase: final Review:
Weeks: Data Xpath:
Xref:

Description

Review UN Locode 2015 for tz codes

We use these for short timezone ids. We stabilize them, but if there are any changes in the Locode, we might want to add aliases.

====

Haven't looked it over in detail, but here is the notice:

http://www.unece.org/fileadmin/DAM/cefact/locode/2015-2_UNLOCODE_SecretariatNotes.pdf

From a quick scan: They've added latitude/longitude (to the minute, ~2km); that's great because often the names of locations are ambiguous.

They still have deviations from the IATA codes, and various strange omissions. And (as you note) they don't include the native name, unless it can be spelled with a subset of Latin-1 characters (ugg). They list the ISO subdivision code sometimes, but no consistent inclusion relations for other codes (eg, they do have that San Francisco is in California, but they miss many other similar relations in other countries). And the latitude/longitude is often missing.

More at http://www.unece.org/cefact/locode/welcome.html

Attachments

Change History

comment:1 Changed 20 months ago by doug@…

BTW, latitude and longitude were first added to UN/LOCODE 13 years ago. See item 6 in the PDF document.

comment:2 Changed 20 months ago by emmons

  • Status changed from new to accepted
  • Component changed from unknown to timezone
  • Phase changed from dsub to final
  • Milestone changed from UNSCH to 29
  • Owner changed from anybody to yoshito
  • Type changed from unknown to spec

comment:3 Changed 20 months ago by yoshito

I think it is not worth adding aliases even original LOCODE was updated. When we assign tz short ID to a new time zone, we use LOCODE as base, but we don't guarantee that the code is kept in sync.

I propose to document that tz short ID is based on LOCODE for most of cases (already documented), but we don't change the code even base LOCODE is changed.

comment:4 follow-up: ↓ 5 Changed 18 months ago by mark

I propose to document that tz short ID is based on LOCODE for most of cases (already documented), but we don't change the code even base LOCODE is changed.

That works for me, as long as we document it.

comment:5 in reply to: ↑ 4 Changed 18 months ago by yoshito

Replying to mark:

I propose to document that tz short ID is based on LOCODE for most of cases (already documented), but we don't change the code even base LOCODE is changed.

That works for me, as long as we document it.

We already have below in tr35.html.


3.6.3 Time Zone Identifiers

LDML inherits time zone IDs from the tz database [Olson]. Because these IDs from the tz database do not satisfy the BCP 47 language subtag syntax requirements, CLDR defines short identifiers for the use in the Unicode locale extension. The short identifiers are defined in the file common/bcp47/timezone.xml.

The short identifiers use UN/LOCODE [LOCODE] (excluding a space character) codes where possible. For example, the short identifier for "America/Los_Angeles" is "uslax" (the LOCODE for Los Angeles, US is "US LAX"). Identifiers of length not equal to 5 are used where there is no corresponding UN/LOCODE, such as "usnavajo" for "America/Shiprock", or "utcw01" for "Etc/GMT+1", so that they do not overlap with future UN/LOCODE.

Although the first two letters of a short identifier may match an ISO 3166 two-letter country code, a user should not assume that the time zone belongs to the country. The first two letters in an identifier of length not equal to 5 has no meaning. Also, the identifiers are stabilized, meaning that they will not change no matter what changes happen in the base standard. So if Hawaii leaves the US and joins Canada as a new province, the short time zone identifier "ushnl" would not change in CLDR even if the UN/LOCODE changes to "cahnl" or something else.

There is a special code "unk" for an Unknown or Invalid time zone. This can be expressed in the tz database style ID "Etc/Unknown", although it is not defined in the tz database.

comment:6 Changed 18 months ago by yoshito

So, our spec already mention that short time zone IDs are based on LOCODE if available, but once an ID is assigned, the ID won't be changed even LOCODE is changed for the specific location.

And I don't think it's worth adding 'aliases' because it will create another level of complication.

So we may check these LOCODE originally used for the short time zone IDs are still active to understand the stability of LOCODE, but even there are changed, no additional tasks on CLDR side.

comment:7 Changed 18 months ago by yoshito

  • Milestone changed from 29 to 30

I'll keep this ticket open for 30 - and will reply to this ticket about changes.

comment:8 Changed 11 months ago by yoshito

  • Milestone changed from 30 to 31

comment:9 Changed 5 months ago by mark

  • Milestone changed from 31 to 32

comment:10 Changed 5 months ago by yoshito

  • Type changed from spec to data

The LDML spec already contains the description explaining the relationship between CLDR short time zone ID and UN LOCODE. So we have nothing to do with spec using this ticket at this point.

We may still want to check if any LOCODE has been changed since we picked them for CLDR tz IDs.

I'll change the bug type from spec to data.

View

Add a comment

Modify Ticket

Action
as accepted
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.