How about adding UN/LOCODE in zone.tab?

Fri Feb 4 16:00:27 UTC 2011

Related to the post below.

Unicode CLDR defines locale identifiers based on BCP47 language tag (
http://www.ietf.org/rfc/bcp/bcp47.txt)
BCP47 provides a mechanism for extending language tags for use in various 
applications.

We recently published RFC6067 (http://datatracker.ietf.org/doc/rfc6067/) 
to allocate BCP47 extension letter "u" for the use of Unicode Locale 
Identifiers. Unicode Locale Identifier has its own subtag for specifying 
time zone IDs. Unfortunately, zone IDs in the tz database cannot be used 
in language tag because each subtag in extension must be 2 to 8 
alpha/numeric characters. For this reason, we defined "short ID" for zones 
based on UN/LOCODE [http://www.unece.org/cefact/locode/]. Most of exemplar 
cities by the tz database are covered by LOCODE, with small exceptions.

For example, zone "America/New_York" is represented by "usnyc". The 
mapping data is provided in the file - 
http://www.unicode.org/repos/cldr/trunk/common/bcp47/timezone.xml

With the extension, you can exchange locale data including time zone 
information with a language tag - for example, "en-US-u-tz-usnyc"

I'm wondering if zone.tab can include LOCODE - for example, LOCODE consist 
from ISO3166 2-letter country code + 3-letter location code.

#locode coordinates     TZ                      comments
AD ALV  +4230+00131     Europe/Andorra
AE DXB  +2518+05518     Asia/Dubai
AF KBL  +3431+06912     Asia/Kabul
AG ANU  +1703-06148     America/Antigua
...

-Yoshito Umaoka (ICU / CLDR project)

Hjwoudenberg <hjwoudenberg at aol.com> wrote on 02/03/2011 07:23:00 PM:

> From: Hjwoudenberg <hjwoudenberg at aol.com>
> To: <tz at lecserver.nci.nih.gov>
> Date: 02/03/2011 07:30 PM
> Subject: RE: lat/lon time offset database
> 
> For time zones I use ISO 3166 country codes and state codes.
> For some states I need a suffix like 'n'  or 'w'  or 's' or 'e' if 
> the state has more than one time zone.
> It also can use the IATA city code, the 3 letter code on your airline 
luggage.
> It contains the time zone rules so each year it calculates the new 
> dates for daylight.
> The rules can be updated on demand, when used first time each year, 
> over the Internet. 
> It also contains the ISO country name, state name and city name and 
> airport name.
> Hope fully the lat/lon for states and countries will someday be 
> available even if they approximate coastlines. 
> These should be a suggestion for the Unicode 
> 
> 
> http://cldr.unicode.org/
> CLDR Project
> 
> The Unicode CLDR provides key building blocks for software to 
> support the world's languages, with the largest and most extensive 
> standard repository of locale data available. This data is used by a
> wide spectrum of companies for their software internationalization 
> and localization, adapting software to the conventions of different 
> languages for such common software tasks as:
> formatting of dates, times, and time zones, 
> formatting numbers and currency values
> sorting text
> choosing languages or countries by name
> 
> http://cldr.unicode.org/index/processIntroduction
> This document describes the Unicode CLDR Technical Committee, and 
> its process for data collection, resolution, public feedback and 
> release. The process is designed to be light-weight: in particular, 
> the meetings are frequent, short, and informal. Most of the work is 
> by email or phone, with a database recording requested changes in data.
> When gathering data for a region and language, it is important to 
> have multiple sources for that data to produce the most widely 
> acceptable data. Initial versions of data were based on the best 
> available sources, but CLDR data will be modified and improved, in 
> successive versions, by more input from the contributors inside and 
> outside of the Unicode Consortium.
> It is important to note that CLDR is a Repository, not a 
> Registration. That is, contributors should not expect that their 
> contributions will simply be adopted into the repository; instead, 
> it will be vetted against the best available information.
> 
> 
> Herman J Woudenberg
> -----Original Message-----
> From: Chris Walton <Chris.Walton at telus.com>
> To: tz at elsie.nci.nih.gov <tz at lecserver.nci.nih.gov>; larry.ober 
> <larry.ober at att.net>
> Sent: Thu, Feb 3, 2011 5:37 pm
> Subject: RE: lat/lon to time offset database

> Larry,
> 
> Just so you know that it is possible… some of the newer GPS units on
> the market today are capable of automatically determining the local time 
zone.
> This is achieved with proprietary time zone maps that are installed 
> inside the GPS at the factory.
> Newer versions of the maps are bundled inside firmware images so 
> that you automatically get the latest map when you upgrade the 
> firmware on your GPS.
> 
> If these built in time zone maps are not accurate (or if you find 
> yourself in an area with disputed time zones), it is possible to 
> turn off automatic mode and then manually enter the time zone of 
> your choosing.
> A Google search reveals that one of the GPS manufacturers stores its
> time zone data in a file that is approximately 600kB.
> I think we can assume that the data in this file is written in a 
> very heavily compressed format; it could theoretically be many 
> megabytes if uncompressed.
> 
> -chris
> 
> From: Larry Ober [mailto:larry.ober at att.net] 
> Sent: February 3, 2011 2:27 PM
> To: tz at lecserver.nci.nih.gov
> Subject: Re: lat/lon to time offset database
> 
> Hi John,
> 
> Well there would be some level of accuracy question. The more 
> accurate the polygon the larger the database. Also if the lat/lon 
> data was provided by GPS, there is the question of signal availability.
> 
> Basically it just seems dumb that I need to tell my GPS what time 
> zone it's in. LOL
> 
> Best Regards
> 
> Larry
> ----- Original Message ----- 
> From: John Haxby 
> To: tz at lecserver.nci.nih.gov 
> Sent: Thursday, February 03, 2011 1:54 PM
> Subject: Re: lat/lon to time offset database
> 
> 
> On 3 Feb 2011, at 18:33, Larry Ober wrote:
> 

> I am looking at building a small embedded system (No OS) that will 
require 
> determining the local time from the lat/lon of a location. So 
> basically I need 
> lat/lon to time offset from "GMT".
> 
> Does that work?   I'm sure I can find places in Spain that are that 
> are close to Lisbon than they are Madrid but being in Spain the 
> timezone should be Europe/Madrid.  Also, when you're on going 
> through the channel tunnel do you go from being closer to Paris than
> you are to London only when you've left Calais?  Or before you get to 
Dover?
> 
> Or have I got hold of the wrong end of the sti 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20110204/c63f4b89/attachment-0001.html 