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@us.ibm.com [mailto:yoshito_umaoka@us.ibm.com] Sent: Friday, February 04, 2011 9:00 AM To: tz@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@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/ <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@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 <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
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.