<font size=2 face="sans-serif">Related to the post below.</font>
<br>
<br><font size=2 face="sans-serif">Unicode CLDR defines locale identifiers
based on BCP47 language tag (</font><a href=http://www.ietf.org/rfc/bcp/bcp47.txt><font size=2 face="sans-serif">http://www.ietf.org/rfc/bcp/bcp47.txt</font></a><font size=2 face="sans-serif">)</font>
<br><font size=2 face="sans-serif">BCP47 provides a mechanism for extending
language tags for use in various applications.</font>
<br>
<br><font size=2 face="sans-serif">We recently published RFC6067 (</font><a href=http://datatracker.ietf.org/doc/rfc6067/><font size=2 face="sans-serif">http://datatracker.ietf.org/doc/rfc6067/</font></a><font size=2 face="sans-serif">)
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 [</font><a href=http://www.unece.org/cefact/locode/><font size=2 face="sans-serif">http://www.unece.org/cefact/locode/</font></a><font size=2 face="sans-serif">].
Most of exemplar cities by the tz database are covered by LOCODE, with
small exceptions.</font>
<br>
<br><font size=2 face="sans-serif">For example, zone "America/New_York"
is represented by "usnyc". The mapping data is provided in the
file - </font><a href=http://www.unicode.org/repos/cldr/trunk/common/bcp47/timezone.xml><font size=2 face="sans-serif">http://www.unicode.org/repos/cldr/trunk/common/bcp47/timezone.xml</font></a>
<br>
<br><font size=2 face="sans-serif">With the extension, you can exchange
locale data including time zone information with a language tag - for example,
"en-US-u-tz-usnyc"</font>
<br>
<br><font size=2 face="sans-serif">I'm wondering if zone.tab can include
LOCODE - for example, LOCODE consist from ISO3166 2-letter country code
+ 3-letter location code.</font>
<br>
<br><font size=2 face="sans-serif">#locode coordinates
TZ
comments</font>
<br><font size=2 face="sans-serif">AD ALV +4230+00131
Europe/Andorra</font>
<br><font size=2 face="sans-serif">AE DXB +2518+05518
Asia/Dubai</font>
<br><font size=2 face="sans-serif">AF KBL +3431+06912
Asia/Kabul</font>
<br><font size=2 face="sans-serif">AG ANU +1703-06148
America/Antigua</font>
<br><font size=2 face="sans-serif">...</font>
<br>
<br><font size=2 face="sans-serif">-Yoshito Umaoka (ICU / CLDR project)</font>
<br>
<br>
<br><tt><font size=2>Hjwoudenberg <hjwoudenberg@aol.com> wrote on
02/03/2011 07:23:00 PM:<br>
<br>
> From: Hjwoudenberg <hjwoudenberg@aol.com></font></tt>
<br><tt><font size=2>> To: <tz@lecserver.nci.nih.gov></font></tt>
<br><tt><font size=2>> Date: 02/03/2011 07:30 PM</font></tt>
<br><tt><font size=2>> Subject: RE: lat/lon time offset database</font></tt>
<br><tt><font size=2>> <br>
> For time zones I use ISO 3166 country codes and state codes.</font></tt>
<br><tt><font size=2>> For some states I need a suffix like 'n' or
'w' or 's' or 'e' if <br>
> the state has more than one time zone.</font></tt>
<br><tt><font size=2>> It also can use the IATA city code, the 3 letter
code on your airline luggage.</font></tt>
<br><tt><font size=2>> It contains the time zone rules so each year
it calculates the new <br>
> dates for daylight.</font></tt>
<br><tt><font size=2>> The rules can be updated on demand, when used
first time each year, <br>
> over the Internet. </font></tt>
<br><tt><font size=2>> It also contains the ISO country name, state
name and city name and <br>
> airport name.</font></tt>
<br><tt><font size=2>> Hope fully the lat/lon for states and countries
will someday be <br>
> available even if they approximate coastlines. </font></tt>
<br><tt><font size=2>> These should be a suggestion for the Unicode
</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> </font></tt><a href=http://cldr.unicode.org/><tt><font size=2>http://cldr.unicode.org/</font></tt></a>
<br><tt><font size=2>> CLDR Project</font></tt>
<br><tt><font size=2>> <br>
> The Unicode CLDR provides key building blocks for software to <br>
> support the world's languages, with the largest and most extensive
<br>
> standard repository of locale data available. This data is used by
a<br>
> wide spectrum of companies for their software internationalization
<br>
> and localization, adapting software to the conventions of different
<br>
> languages for such common software tasks as:</font></tt>
<br><tt><font size=2>> formatting of dates, times, and time zones, </font></tt>
<br><tt><font size=2>> formatting numbers and currency values</font></tt>
<br><tt><font size=2>> sorting text</font></tt>
<br><tt><font size=2>> choosing languages or countries by name</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> </font></tt><a href=http://cldr.unicode.org/index/processIntroduction><tt><font size=2>http://cldr.unicode.org/index/processIntroduction</font></tt></a>
<br><tt><font size=2>> This document describes the Unicode CLDR Technical
Committee, and <br>
> its process for data collection, resolution, public feedback and <br>
> release. The process is designed to be light-weight: in particular,
<br>
> the meetings are frequent, short, and informal. Most of the work is
<br>
> by email or phone, with a database recording requested changes in
data.</font></tt>
<br><tt><font size=2>> When gathering data for a region and language,
it is important to <br>
> have multiple sources for that data to produce the most widely <br>
> acceptable data. Initial versions of data were based on the best <br>
> available sources, but CLDR data will be modified and improved, in
<br>
> successive versions, by more input from the contributors inside and
<br>
> outside of the Unicode Consortium.</font></tt>
<br><tt><font size=2>> It is important to note that CLDR is a Repository,
not a <br>
> Registration. That is, contributors should not expect that their <br>
> contributions will simply be adopted into the repository; instead,
<br>
> it will be vetted against the best available information.</font></tt>
<br><tt><font size=2>> <br>
> </font></tt>
<br><tt><font size=2>> Herman J Woudenberg</font></tt>
<br><tt><font size=2>> -----Original Message-----<br>
> From: Chris Walton <Chris.Walton@telus.com><br>
> To: tz@elsie.nci.nih.gov <tz@lecserver.nci.nih.gov>; larry.ober
<br>
> <larry.ober@att.net><br>
> Sent: Thu, Feb 3, 2011 5:37 pm<br>
> Subject: RE: lat/lon to time offset database<br>
</font></tt>
<br><tt><font size=2>> Larry,</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> Just so you know that it is possible… some of
the newer GPS units on<br>
> the market today are capable of automatically determining the local
time zone.</font></tt>
<br><tt><font size=2>> This is achieved with proprietary time zone maps
that are installed <br>
> inside the GPS at the factory.</font></tt>
<br><tt><font size=2>> Newer versions of the maps are bundled inside
firmware images so <br>
> that you automatically get the latest map when you upgrade the <br>
> firmware on your GPS.</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> If these built in time zone maps are not accurate
(or if you find <br>
> yourself in an area with disputed time zones), it is possible to <br>
> turn off automatic mode and then manually enter the time zone of <br>
> your choosing.</font></tt>
<br><tt><font size=2>> A Google search reveals that one of the GPS manufacturers
stores its<br>
> time zone data in a file that is approximately 600kB.</font></tt>
<br><tt><font size=2>> I think we can assume that the data in this file
is written in a <br>
> very heavily compressed format; it could theoretically be many <br>
> megabytes if uncompressed.</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> -chris</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> From: Larry Ober [</font></tt><a href=mailto:larry.ober@att.net><tt><font size=2>mailto:larry.ober@att.net</font></tt></a><tt><font size=2>]
<br>
> Sent: February 3, 2011 2:27 PM<br>
> To: tz@lecserver.nci.nih.gov<br>
> Subject: Re: lat/lon to time offset database</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> Hi John,</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> Well there would be some level of accuracy question.
The more <br>
> accurate the polygon the larger the database. Also if the lat/lon
<br>
> data was provided by GPS, there is the question of signal availability.</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> Basically it just seems dumb that I need to tell
my GPS what time <br>
> zone it's in. LOL</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> Best Regards</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> Larry</font></tt>
<br><tt><font size=2>> ----- Original Message ----- </font></tt>
<br><tt><font size=2>> From: John Haxby </font></tt>
<br><tt><font size=2>> To: tz@lecserver.nci.nih.gov </font></tt>
<br><tt><font size=2>> Sent: Thursday, February 03, 2011 1:54 PM</font></tt>
<br><tt><font size=2>> Subject: Re: lat/lon to time offset database</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> On 3 Feb 2011, at 18:33, Larry Ober wrote:</font></tt>
<br><tt><font size=2>> <br>
</font></tt>
<br><tt><font size=2>> I am looking at building a small embedded system
(No OS) that will require <br>
> determining the local time from the lat/lon of a location. So <br>
> basically I need <br>
> lat/lon to time offset from "GMT".</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> Does that work? I'm sure I can find places
in Spain that are that <br>
> are close to Lisbon than they are Madrid but being in Spain the <br>
> timezone should be Europe/Madrid. Also, when you're on going
<br>
> through the channel tunnel do you go from being closer to Paris than<br>
> you are to London only when you've left Calais? Or before you
get to Dover?</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> Or have I got hold of the wrong end of the sti
</font></tt>