Date Countries Switch to/from DST

Fri Feb 4 17:15:56 UTC 2011

I’m trying to get this mail through to the email list & it gave me an error.

Can you help me get it through? If you already received it through my attempt, please disregard.

Thanks

Here’s the message:

Hello list,

I am also a Timezone newbie.

I need to get a dump of the tz database for all countries in the world, which timezone they are in, and what date they switch on/off DST.  I’m not interested in getting real time dates; I just need a refresh of the database periodically.

Can somebody tell me how I would get this?  Is there a site that I can get the data from?

Thanks

Bonnie K. O'Neil

CBIP, CDMP

Enterprise Data Architect

Travelport Global Technology Solutions

Office: 303-397-5239

Mobile: 303-725-1737

From: yoshito_umaoka at us.ibm.com [mailto:yoshito_umaoka at us.ibm.com] 
Sent: Friday, February 04, 2011 9:00 AM
To: tz at lecserver.nci.nih.gov
Subject: How about adding UN/LOCODE in zone.tab?

Related to the post below. 

Unicode CLDR defines locale identifiers based on BCP47 language tag (http://www.ietf.org/rfc/bcp/bcp47.txt <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/ <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/ <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 <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/ <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 <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 <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 

If you are not the intended recipient of this e-mail message, please notify the sender 
and delete all copies immediately. The sender believes this message and any attachments 
were sent free of any virus, worm, Trojan horse, and other forms of malicious code. 
This message and its attachments could have been infected during transmission. The 
recipient opens any attachments at the recipient's own risk, and in so doing, the 
recipient accepts full responsibility for such actions and agrees to take protective 
and remedial action relating to any malicious code. Travelport is not liable for any 
loss or damage arising from this message or its attachments.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20110204/6a1bcff0/attachment-0001.html 