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

> From: Hjwoudenberg <hjwoudenberg@aol.com>
> To: <tz@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@telus.com>

> To: tz@elsie.nci.nih.gov <tz@lecserver.nci.nih.gov>; larry.ober

> <larry.ober@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@att.net
]

> Sent: February 3, 2011 2:27 PM

> To: tz@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@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