I'm a nubie at understanding the ins and outs of timezones so please forgive me for my potentially dumb questions. 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". I don't really need the geo political information like country or city. However it seems like tz is structured continent/country/city/... Now maybe I already have what I need but I just don't understand it. I have a copy of timezone.csv that seems to include data from country code to city etc. This seems to point to what looks like coordinate data that I don't understand. An example for America/New York seems to point to an area 115. There then seem to be multiple 115 entries like the following; 115, 3907893600, -18000, EST, 0 115, 3919388400, -14400, EDT, 1 My interpretation is that 115 is the area, the next column should be some sort of latitude, next seems to be called an offset in other contexts, next is the used name of the zone followed by a true/false bit. If this is basically true, I guess that what I don't understand it how to "parse" the latitude and how to use the longitude offset. Of course maybe I have this entirely wrong. I would appreciate any help on this basic issue. Regards Larry
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 stick? jch
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 stick? jch
Date: Thu, 3 Feb 2011 14:27:29 -0500 From: Larry Ober <larry.ober@att.net> Message-ID: <5C437F3DECC04DDBA730DC02BA7E00C1@OfficePC> | Basically it just seems dumb that I need to tell my GPS what time zone = | it's in. LOL Unfortunately it is the only way that works reliably - you (or someone) have to set it (if you have a 3G or something interface, as well as a GPS receiver, the local phone company may broadcast local time, and you could work out the timezone offset from that (or of course, you could just use their time setting...) The problem is that even if you do all the work that others have suggested, to collect all the boundary data (and you could actually convince yourself that your data actually matches the actual practices - which means that the nominal political boundaries aren't always appropriate), you still end up with just knowing the zone you're in, and not necessarily the correct offset. You can believe what's in the database, but that's only accurate if your device has a current copy, the data changes many times a year. If your device has the ability to fetch updated database copies when they're needed, then it must be connected to the net somehow, and if it is, it can probably make use of that to find some local system with local time that you can get. Time seems like it really ought to be simple to deal with, unfortunately it is absurdly complex. kre
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<mailto:john.haxby@oracle.com> To: tz@lecserver.nci.nih.gov<mailto: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 stick? jch
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/processIntroductionThis 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
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@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
On 04/02/11 16:00, yoshito_umaoka@us.ibm.com wrote:
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)
Including LOCODE in zone.tab may or may not be a good idea, but I'm trying hard to think why you'd want to encode a time zone in a language tag. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
More on those at http://cldr.unicode.org/index/bcp47-extension Mark *— Il meglio è l’inimico del bene —* On Fri, Feb 4, 2011 at 08:35, Ian Abbott <abbotti@mev.co.uk> wrote:
On 04/02/11 16:00, yoshito_umaoka@us.ibm.com wrote:
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)
Including LOCODE in zone.tab may or may not be a good idea, but I'm trying hard to think why you'd want to encode a time zone in a language tag.
-- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Sorry I am also new to this and am trying to understand how the rule below is applied: # Ghana # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Ghana 1936 1942 - Sep 1 0:00 0:20 GHST Rule Ghana 1936 1942 - Dec 31 0:00 0 GMT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana %s I read it as "Ghana" rules were only in effect from 1936 to 1942. After 1918, Accra uses that rule, but therefore only from 1936 to 1942? So after 1942 what applies? No rules, but the letters still are in effect, therefore "GMT"? [Likewise - not relevant to me, but what about Accra for 1919 - 1936 ?] Thanks, Matt Taylor
Starting in 1918 they used Ghana GMT (0:00 offset) Then from 1936 - 42 they used Ghana GHST from September thru December. They remain on Ghana GMT. Interesting case though, that they moved their clocks forward only in the fall, and only 20 minutes. On 2011-02-04 14:54, mxtaylor@ups.com wrote:
Sorry I am also new to this and am trying to understand how the rule below is applied: # Ghana # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Ghana 1936 1942 - Sep 1 0:00 0:20 GHST Rule Ghana 1936 1942 - Dec 31 0:00 0 GMT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana %s I read it as "Ghana" rules were only in effect from 1936 to 1942. After 1918, Accra uses that rule, but therefore only from 1936 to 1942? So after 1942 what applies? No rules, but the letters still are in effect, therefore "GMT"? [Likewise - not relevant to me, but what about Accra for 1919 - 1936 ?] Thanks, Matt Taylor
<<On Fri, 4 Feb 2011 14:54:21 -0500, <mxtaylor@ups.com> said:
Sorry I am also new to this and am trying to understand how the rule below is applied: # Ghana # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Ghana 1936 1942 - Sep 1 0:00 0:20 GHST Rule Ghana 1936 1942 - Dec 31 0:00 0 GMT
I read it as "Ghana" rules were only in effect from 1936 to 1942.
This is a common confusion. The Rule statements generate transitions; in this case, every year between 1936 and 1942, two transitions are generated, one from GMT to GHST (save 20 minutes), and one from GHST to GMT. Since no transitions happen after December 31, 1942, Ghana remains on GMT. -GAWollman
On Feb 4, 2011, at 8:35 AM, Ian Abbott wrote:
Including LOCODE in zone.tab may or may not be a good idea, but I'm trying hard to think why you'd want to encode a time zone in a language tag.
If by "with a language tag" he means that en-US-u-tz-usnyc" is a language tag, yes, that's bogus. If, however, he means that "en-US-u-tz-usnyc" is a locale tag, which includes a language tag but can include more information as well, that makes sense. Unfortunately, RFC 6067 calls it a "language tag", which is a bogus term for anything that specifies time zones, collating orders, and other information that has nothing to do with language. The RFC says: %% Identifier: u Description: Unicode Locale Comments: Subtags for the identification of language and cultural variations. Used to set behavior in locale APIs. Data is located in the "common/bcp47" directory inside the referenced URL. Unicode Technical Standard #35 (LDML) provides additional reference material defining the keys and values. For more details please see <http://cldr.unicode.org/index/bcp47-extension>. Added: 2010-09-02 RFC: RFC 6067 Authority: Unicode Consortium Contact_Email: cldr-contact@unicode.org Mailing_List: cldr-users@unicode.org URL: http://www.unicode.org/Public/cldr/latest/core.zip %% I'm not sure whether the time zone counts as a "cultural variation"; it's definitely not a "language variation". The CLDR page linked to says The subtags available for use in the 'u' extension provide language tag extensions that provide for additional information needed for identifying *locales*. which suggests that, with the addition of "u-XX-YY" items, what you have really isn't a "language tag" any more, it's a "language and locale tag" (unless "locale" includes language, so that, for example, many of the locations on the planet have more than one locale, and some even *officially* have more than one locale, in which case it's a "locale tag").
On Feb 4, 2011, at 4:00 PM, Guy Harris wrote:
On Feb 4, 2011, at 8:35 AM, Ian Abbott wrote:
Including LOCODE in zone.tab may or may not be a good idea, but I'm trying hard to think why you'd want to encode a time zone in a language tag.
If by "with a language tag" he means that en-US-u-tz-usnyc" is a language tag, yes, that's bogus.
If, however, he means that "en-US-u-tz-usnyc" is a locale tag, which includes a language tag but can include more information as well, that makes sense. Unfortunately, RFC 6067 calls it a "language tag", which is a bogus term for anything that specifies time zones, collating orders, and other information that has nothing to do with language.
At the risk of going off topic for this list, collating order certainly is (largely) a language question. Not entirely; some languages may have a choice of several collating orders based on national or cultural differences. I do agree that timezone is in no way a language related thing. paul
Paul Koning <paul_koning@dell.com> wrote on 02/04/2011 05:14:39 PM:
From: Paul Koning <paul_koning@dell.com> To: <tz@lecserver.nci.nih.gov>, Guy Harris <guy@alum.mit.edu> Date: 02/04/2011 05:19 PM Subject: Re: How about adding UN/LOCODE in zone.tab?
On Feb 4, 2011, at 4:00 PM, Guy Harris wrote:
On Feb 4, 2011, at 8:35 AM, Ian Abbott wrote:
Including LOCODE in zone.tab may or may not be a good idea, but I'm trying hard to think why you'd want to encode a time zone in a
language tag.
If by "with a language tag" he means that en-US-u-tz-usnyc" is a
language tag, yes, that's bogus.
If, however, he means that "en-US-u-tz-usnyc" is a locale tag,
which includes a language tag but can include more information as well, that makes sense. Unfortunately, RFC 6067 calls it a "language tag", which is a bogus term for anything that specifies time zones, collating orders, and other information that has nothing to do with language.
At the risk of going off topic for this list, collating order certainly is (largely) a language question. Not entirely; some languages may have a choice of several collating orders based on national or cultural differences.
I do agree that timezone is in no way a language related thing.
timezone is not a language related thing. And strictly speaking, "en-US-u-tz-usnyc" is a BCP 47 language tag representing information used for identifying a locale. See the definition of extension subtags in BCP 47 below - 2.2.6. Extension Subtags Extensions provide a mechanism for extending language tags for use in various applications. They are intended to identify information that is commonly used in association with languages or language tags but that is not part of language identification. See Section 3.7. The following rules apply to extensions: Anyway, the definition of language tags or locale identifiers is out of the scope of this ML. If you have any comments, I'd recommend you to post your message to CLDR or LTRU mailing list. -Yoshito
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.
On Fri, Feb 4, 2011 at 11:15 AM, O'Neil, Bonnie <bonnie.oneil@travelport.com> wrote:
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.
You can download the tz database at http://www.twinsun.com/tz/tz-link.htm . Mostly for my own benefit, I wrote a little paper about how to read tz's source files: http://www.cstdbill.com/tzdb/db.html . Hope that helps, --Bill
Wow!! Thanks so very much! Bonnie K. O'Neil CBIP, CDMP Enterprise Data Architect Travelport Global Technology Solutions Office: 303-397-5239 Mobile: 303-725-1737 -----Original Message----- From: billseymour@gmail.com [mailto:billseymour@gmail.com] On Behalf Of Bill Seymour Sent: Friday, February 04, 2011 2:29 PM To: tz@lecserver.nci.nih.gov Subject: Re: Date Countries Switch to/from DST On Fri, Feb 4, 2011 at 11:15 AM, O'Neil, Bonnie <bonnie.oneil@travelport.com> wrote:
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.
You can download the tz database at http://www.twinsun.com/tz/tz-link.htm . Mostly for my own benefit, I wrote a little paper about how to read tz's source files: http://www.cstdbill.com/tzdb/db.html . Hope that helps, --Bill 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.
On Feb 4, 2011, at 9:15 AM, O'Neil, Bonnie wrote:
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.
Note that "the tz database", in the sense of the database available for FTP from elsie.nci.nih.gov (which is where the tz-link.htm page points), and which this list discusses, doesn't directly have "countries"; the name of a "time zone" in the database corresponds to a "location" - to quote the tz-link.htm page: Each location in the database represents a national region where all clocks keeping local time have agreed since 1970. Locations are identified by continent or ocean and then by the name of the location, which is typically the largest city within the region. For example, America/New_York represents most of the US eastern time zone; America/Phoenix represents most of Arizona, which uses mountain time without daylight saving time (DST); America/Detroit represents most of Michigan, which uses eastern time but with different DST rules in 1975; and other entries represent smaller regions like Starke County, Indiana, which switched from central to eastern time in 1991 and switched back in 2006. I infer from your company's name and Web site that one thing you probably need is a way to map a geographical location to a tz database location (for example, "what timezone is Paris in and when do they switch on/off DST?"). The tz database doesn't itself provide that, but at http://efele.net/maps/tz/world/ you can get a file that shows the boundaries of tz database locations; at http://www.manifold.net/info/freestuff.shtml are a bunch of data sets, include a map of "World Time Zones", although they don't say whether that's a map of tz database locations or not.
Guy, You are right. As we understand it, countries may make an announcement that they will be observing DST this year on such and such a date. What we need is to keep track of these pronouncements as they relate to our flight schedules. We will have to map countries & cities to the locations. I will check out the resources you site here. This list has been very helpful! Bonnie K. O'Neil CBIP, CDMP Enterprise Data Architect Travelport Global Technology Solutions Office: 303-397-5239 Mobile: 303-725-1737 -----Original Message----- From: Guy Harris [mailto:guy@alum.mit.edu] Sent: Friday, February 04, 2011 4:12 PM To: tz@lecserver.nci.nih.gov Subject: Re: Date Countries Switch to/from DST On Feb 4, 2011, at 9:15 AM, O'Neil, Bonnie wrote:
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.
Note that "the tz database", in the sense of the database available for FTP from elsie.nci.nih.gov (which is where the tz-link.htm page points), and which this list discusses, doesn't directly have "countries"; the name of a "time zone" in the database corresponds to a "location" - to quote the tz-link.htm page: Each location in the database represents a national region where all clocks keeping local time have agreed since 1970. Locations are identified by continent or ocean and then by the name of the location, which is typically the largest city within the region. For example, America/New_York represents most of the US eastern time zone; America/Phoenix represents most of Arizona, which uses mountain time without daylight saving time (DST); America/Detroit represents most of Michigan, which uses eastern time but with different DST rules in 1975; and other entries represent smaller regions like Starke County, Indiana, which switched from central to eastern time in 1991 and switched back in 2006. I infer from your company's name and Web site that one thing you probably need is a way to map a geographical location to a tz database location (for example, "what timezone is Paris in and when do they switch on/off DST?"). The tz database doesn't itself provide that, but at http://efele.net/maps/tz/world/ you can get a file that shows the boundaries of tz database locations; at http://www.manifold.net/info/freestuff.shtml are a bunch of data sets, include a map of "World Time Zones", although they don't say whether that's a map of tz database locations or not. 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.
On Fri, Feb 4, 2011 at 5:44 PM, O'Neil, Bonnie <bonnie.oneil@travelport.com> wrote:
Guy, You are right. As we understand it, countries may make an announcement that they will be observing DST this year on such and such a date. What we need is to keep track of these pronouncements as they relate to our flight schedules.
You might find that such announcements arrive more quickly at http://www.timeanddate.com/ I say that because a fellow named Steffen Thorsen often provides this list with links to timeanddate.com pages that, in turn, provide links to original source documents. --Bill
Bill, Thanks again! Can I subscribe to this data? I really like the format. I read all of their usage policies and there really doesn't seem to be any disclaimer (like the one on WorldTimeZone.com) that disallows screen scraping or subscriptions to the data itself. Thanks Bonnie K. O'Neil CBIP, CDMP Enterprise Data Architect Travelport Global Technology Solutions Office: 303-397-5239 Mobile: 303-725-1737 -----Original Message----- From: billseymour@gmail.com [mailto:billseymour@gmail.com] On Behalf Of Bill Seymour Sent: Saturday, February 05, 2011 6:25 AM To: tz@lecserver.nci.nih.gov Subject: Re: Date Countries Switch to/from DST On Fri, Feb 4, 2011 at 5:44 PM, O'Neil, Bonnie <bonnie.oneil@travelport.com> wrote:
Guy, You are right. As we understand it, countries may make an announcement that they will be observing DST this year on such and such a date. What we need is to keep track of these pronouncements as they relate to our flight schedules.
You might find that such announcements arrive more quickly at http://www.timeanddate.com/ I say that because a fellow named Steffen Thorsen often provides this list with links to timeanddate.com pages that, in turn, provide links to original source documents. --Bill 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.
John Haxby said:
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?
Well, yes, if you have a detailed enough set of polygons. But that's the difficult bit.
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?
By rail the distance is 491.5 km. The tunnel portals are 162.05 (France) and 111.60 (UK) km from London. The 245.75 point is just west of the Erquinghem crossovers near Armentieres, about 21.4km west of Lille station. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Actually neither, you should use the international boundary line for this. Alternatively, if you were going by ferry, then ships are free to keep whatever TZ they wish, though the guidance is the 7.5 degree zones with no summer time/DST, and the usual bumps around the date line.
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?
By rail the distance is 491.5 km. The tunnel portals are 162.05 (France) and 111.60 (UK) km from London. The 245.75 point is just west of the Erquinghem crossovers near Armentieres, about 21.4km west of Lille station. Tim Smartcom Software Ltd Portsmouth Technopole Kingston Crescent Portsmouth PO2 8FA United Kingdom www.smartcomsoftware.com Smartcom Software is a limited company registered in England and Wales, registered number 05641521.
Tim Thornton said:
Actually neither, you should use the international boundary line for this.
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?
Actually, all of Eurotunnel - including the parts in the UK - use French time. The actual time change happens at the boundary between Eurotunnel and Network Rail track, 108.56km from London (and 3.04km from the UK portal). -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Hi, Does anyone know how to remove myself from the mailing lists? I do not work on any tz related projects, and do not wish to be notified. I have checked aps.oraclecorp.com, but it doesn't seem to list the mailing list as one that I have signed up for. Thanks
On Feb 3, 2011, at 1:33 PM, Larry Ober wrote:
I'm a nubie at understanding the ins and outs of timezones so please forgive me for my potentially dumb questions.
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".
I don't really need the geo political information like country or city. However it seems like tz is structured continent/country/city/...
Actually, you do. What you're trying to do may be too hard for a "small embedded system" (depending on what "small" means). The problem you're up against is that timezones are political constructs. To know the timezone for a spot on the globe, you have to know what political subdivision it's in; that will tell you what the timezone rule (law or regulation) is that applies to it. For example, if your position is 41 N, 71 W, that puts you in a part of the USA that uses the Americas/New_York rules (US Eastern Time with daylight savings). On the other hand, if you're at 35 40 N, 109 03 W, you're in US Mountain time with DST, and move to 35 40 N, 111 30 W, now you're still in US Mountain Time but you've lost DST. So you need a database of zone boundaries -- which is likely to be fairly large. Then you figure out which polygon in that database contains your current position. From that, you have the zone rule that applies to this position. The zone.tab file might seem like a starting point, but it isn't really; it just lists each of the zones with a single point in that zone. What you need is the analog of zone.tab but with the bounding polygon for each zone rather than a point inside it. I believe that data exists somewhere, but I don't remember the location. paul
On Thu, Feb 3, 2011 at 19:54, Paul Koning <paul_koning@dell.com> wrote:
So you need a database of zone boundaries -- which is likely to be fairly large. Then you figure out which polygon in that database contains your current position. From that, you have the zone rule that applies to this position.
Having spent a little time trying to extract country boundaries from the openstreetmap data, (a) it's not very trivial to get right (and this might be even harder to do correctly for timezone borders, because they're less relevant to mapmakers), and (b) yes, it's substantial amount of data. Depending on if the embedded device is mobile or not, maybe you could start by using a GeoIP-like service. Cheers, Dirkjan
What you need is the analog of zone.tab but with the bounding polygon for each zone rather than a point inside it. I believe that data exists somewhere, but I don't remember the location.
For mapping lon/lats to timezones I use the maps that can be downloaded from this location: http://efele.net/maps/tz/world/ Just bear in mind the maps do not cover sea lon/lat's only land. Paw --------------------------- DISCLAIMER: The information contained in this electronic message and in any attachments to this message is intended only for the person or entity to which this electronic message is addressed. If you are not the intended recipient, you are hereby notified that any distribution, copying, review, retransmission, dissemination or other use of this electronic transmission or the information contained in it is strictly prohibited. -----Original Message----- From: Paul Koning [mailto:paul_koning@Dell.com] Sent: 04 February 2011 02:54 To: tz@lecserver.nci.nih.gov; Larry Ober Subject: Re: lat/lon to time offset database On Feb 3, 2011, at 1:33 PM, Larry Ober wrote:
I'm a nubie at understanding the ins and outs of timezones so please forgive me for my potentially dumb questions.
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".
I don't really need the geo political information like country or city. However it seems like tz is structured continent/country/city/...
Actually, you do. What you're trying to do may be too hard for a "small embedded system" (depending on what "small" means). The problem you're up against is that timezones are political constructs. To know the timezone for a spot on the globe, you have to know what political subdivision it's in; that will tell you what the timezone rule (law or regulation) is that applies to it. For example, if your position is 41 N, 71 W, that puts you in a part of the USA that uses the Americas/New_York rules (US Eastern Time with daylight savings). On the other hand, if you're at 35 40 N, 109 03 W, you're in US Mountain time with DST, and move to 35 40 N, 111 30 W, now you're still in US Mountain Time but you've lost DST. So you need a database of zone boundaries -- which is likely to be fairly large. Then you figure out which polygon in that database contains your current position. From that, you have the zone rule that applies to this position. The zone.tab file might seem like a starting point, but it isn't really; it just lists each of the zones with a single point in that zone. What you need is the analog of zone.tab but with the bounding polygon for each zone rather than a point inside it. I believe that data exists somewhere, but I don't remember the location. paul
On Feb 3, 2011, at 10:54 AM, Paul Koning wrote:
The zone.tab file might seem like a starting point, but it isn't really; it just lists each of the zones with a single point in that zone. What you need is the analog of zone.tab but with the bounding polygon for each zone rather than a point inside it. I believe that data exists somewhere, but I don't remember the location.
The tz-link.htm file I mentioned in my previous message has a section "Time zone boundaries" that says: • TZ timezone maps contains a shapefile of the tz regions in the world. • Administrative Divisions of Countries ("Statoids") contains detailed lists of tz-related zone subdivision data. • Time zone boundaries for multizone countries summarizes legal boundaries between time zones within countries. • Manifold.net's Free Maps and GIS Data includes a Manifold-format map of world time zone boundaries distributed under the GPL. • The US Geological Survey's National Atlas of the United States publishes the Time Zones of the United States in the public domain. • The GeoCommunity lists several commercial sources for International Time Zones and Time Zone Data. • A ship within the territorial waters of any nation uses that nation's time. In international waters, time zone boundaries are meridians 15° apart, except that UTC−12 and UTC+12 are each 7.5° wide and are separated by the 180° meridian (not by the International Date Line, which is for land and territorial waters only). A captain can change ship's clocks any time after entering a new time zone; midnight changes are common. The links for those are: http://efele.net/maps/tz/ - the "TZ timezone maps" link (mentioned in another message); "shapefile" links to http://en.wikipedia.org/wiki/Shapefile, which describes what a shapefile is http://statoids.com/statoids.html - "Administrative Divisions of Countries ("Statoids") http://home.tiscali.nl/~t876506/Multizones.html - "Time zone boundaries for multizone countries" http://www.manifold.net/download/freemaps.html - "Manifold.net's Free Maps and GIS Data", but that link no longer works http://nationalatlas.gov/mld/timeznp.html - "Time Zones of the United States" http://spatialnews.geocomm.com/features/timezones/ - "The GeoCommunity lists several commercial sources for International Time Zones and Time Zone Data."
Thanks Guy, Regards Larry ----- Original Message ----- From: "Guy Harris" <guy@alum.mit.edu> To: <tz@lecserver.nci.nih.gov> Cc: "Larry Ober" <larry.ober@att.net> Sent: Thursday, February 03, 2011 2:41 PM Subject: Re: lat/lon to time offset database
On Feb 3, 2011, at 10:54 AM, Paul Koning wrote:
The zone.tab file might seem like a starting point, but it isn't really; it just lists each of the zones with a single point in that zone. What you need is the analog of zone.tab but with the bounding polygon for each zone rather than a point inside it. I believe that data exists somewhere, but I don't remember the location.
The tz-link.htm file I mentioned in my previous message has a section "Time zone boundaries" that says:
• TZ timezone maps contains a shapefile of the tz regions in the world. • Administrative Divisions of Countries ("Statoids") contains detailed lists of tz-related zone subdivision data. • Time zone boundaries for multizone countries summarizes legal boundaries between time zones within countries. • Manifold.net's Free Maps and GIS Data includes a Manifold-format map of world time zone boundaries distributed under the GPL. • The US Geological Survey's National Atlas of the United States publishes the Time Zones of the United States in the public domain. • The GeoCommunity lists several commercial sources for International Time Zones and Time Zone Data. • A ship within the territorial waters of any nation uses that nation's time. In international waters, time zone boundaries are meridians 15° apart, except that UTC−12 and UTC+12 are each 7.5° wide and are separated by the 180° meridian (not by the International Date Line, which is for land and territorial waters only). A captain can change ship's clocks any time after entering a new time zone; midnight changes are common.
The links for those are:
http://efele.net/maps/tz/ - the "TZ timezone maps" link (mentioned in another message); "shapefile" links to http://en.wikipedia.org/wiki/Shapefile, which describes what a shapefile is
http://statoids.com/statoids.html - "Administrative Divisions of Countries ("Statoids")
http://home.tiscali.nl/~t876506/Multizones.html - "Time zone boundaries for multizone countries"
http://www.manifold.net/download/freemaps.html - "Manifold.net's Free Maps and GIS Data", but that link no longer works
http://nationalatlas.gov/mld/timeznp.html - "Time Zones of the United States"
http://spatialnews.geocomm.com/features/timezones/ - "The GeoCommunity lists several commercial sources for International Time Zones and Time Zone Data."
Guy Harris <guy@alum.mit.edu> wrote:
http://www.manifold.net/download/freemaps.html - "Manifold.net's Free Maps and GIS Data", but that link no longer works
Looks like it is now http://www.manifold.net/info/freestuff.shtml Thanks for the other links. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
On 03.02.11 19:54, Paul Koning wrote: What you need is the analog of zone.tab but with the bounding
polygon for each zone rather than a point inside it. I believe that data exists somewhere, but I don't remember the location.
If you do remember, PLEASE let me know. I have been dreaming about this since years.
On Feb 3, 2011, at 12:22 PM, Alois Treindl wrote:
On 03.02.11 19:54, Paul Koning wrote:
What you need is the analog of zone.tab but with the bounding polygon for each zone rather than a point inside it. I believe that data exists somewhere, but I don't remember the location.
If you do remember, PLEASE let me know. I have been dreaming about this since years.
To quote Paw Nielsen's message:
For mapping lon/lats to timezones I use the maps that can be downloaded from this location: http://efele.net/maps/tz/world/
Just bear in mind the maps do not cover sea lon/lat's only land.
As for the sea, the tz-link.htm file in the tzcode distribution says • A ship within the territorial waters of any nation uses that nation's time. In international waters, time zone boundaries are meridians 15° apart, except that UTC−12 and UTC+12 are each 7.5° wide and are separated by the 180° meridian (not by the International Date Line, which is for land and territorial waters only). A captain can change ship's clocks any time after entering a new time zone; midnight changes are common.
On Feb 3, 2011, at 10:33 AM, Larry Ober wrote:
I don't really need the geo political information like country or city. However it seems like tz is structured continent/country/city/...
To quote the tz-link.htm file in the tzcode package: Each location in the database represents a national region where all clocks keeping local time have agreed since 1970. Locations are identified by continent or ocean and then by the name of the location, which is typically the largest city within the region. For example, America/New_York represents most of the US eastern time zone; America/Phoenix represents most of Arizona, which uses mountain time without daylight saving time (DST); America/Detroit represents most of Michigan, which uses eastern time but with different DST rules in 1975; and other entries represent smaller regions like Starke County, Indiana, which switched from central to eastern time in 1991 and switched back in 2006.
Now maybe I already have what I need but I just don't understand it. I have a copy of timezone.csv that seems to include data from country code to city etc.
If I search for timezone.csv on Google, I get hits for at least two different data sets: http://code.google.com/p/x-wrt/source/browse/trunk/package/webif/files/usr/l... which doesn't seem to include any coordinate information, and http://msdn.microsoft.com/en-us/library/aa458853.aspx which says the timezone.csv file "contains the Timezone Index, GMT Differential, and Description for each time zone". Where did you get that timezone.csv from?
This seems to point to what looks like coordinate data that I don't understand.
An example for America/New York seems to point to an area 115. There then seem to be multiple 115 entries like the following;
115, 3907893600, -18000, EST, 0 115, 3919388400, -14400, EDT, 1
My interpretation is that 115 is the area, the next column should be some sort of latitude, next seems to be called an offset in other contexts, next is the used name of the zone followed by a true/false bit.
*My* guess is that 115 is some representation of an area, 3907893600 is some representation of a time when the US Eastern time zone switches to Standard time, -18000 is the offset in seconds from UTC to use for the time zone after that time, "EST" is the abbreviation to use for the time zone after that time, and 0 is a "Daylight Savings Time is not in effect" indication. I.e., if you sort all the entries for a given area by the second field, it's a list of standard <-> {daylight savings, summer} time transitions, with each entry saying when the transition occurs, what the offset from GMT in seconds is after that transition, what the zone abbreviation is after that transition, and whether you're in standard or {summer, daylight savings} time after that transition.
Hi Guy, Oh I'm not sure. It may have been Microsoft. I was too naive when I found it. I thought that I had the answer. There are about 579 pairs of 115 EST/EDT "pairs" I was hoping this was the zone description of some sort. I was pretty convinced that the 115 part referred to the US eastern time zone. The file seem pretty logical to follow starting with a 2 character country code on down. All US eastern time zone entries contain 115 in one of the columns Thanks for pointing out that the offset is in seconds! Regards Larry ----- Original Message ----- From: "Guy Harris" <guy@alum.mit.edu> To: <tz@lecserver.nci.nih.gov> Sent: Thursday, February 03, 2011 2:31 PM Subject: Re: lat/lon to time offset database
On Feb 3, 2011, at 10:33 AM, Larry Ober wrote:
I don't really need the geo political information like country or city. However it seems like tz is structured continent/country/city/...
To quote the tz-link.htm file in the tzcode package:
Each location in the database represents a national region where all clocks keeping local time have agreed since 1970. Locations are identified by continent or ocean and then by the name of the location, which is typically the largest city within the region. For example, America/New_York represents most of the US eastern time zone; America/Phoenix represents most of Arizona, which uses mountain time without daylight saving time (DST); America/Detroit represents most of Michigan, which uses eastern time but with different DST rules in 1975; and other entries represent smaller regions like Starke County, Indiana, which switched from central to eastern time in 1991 and switched back in 2006.
Now maybe I already have what I need but I just don't understand it. I have a copy of timezone.csv that seems to include data from country code to city etc.
If I search for timezone.csv on Google, I get hits for at least two different data sets:
http://code.google.com/p/x-wrt/source/browse/trunk/package/webif/files/usr/l...
which doesn't seem to include any coordinate information, and
http://msdn.microsoft.com/en-us/library/aa458853.aspx
which says the timezone.csv file "contains the Timezone Index, GMT Differential, and Description for each time zone".
Where did you get that timezone.csv from?
This seems to point to what looks like coordinate data that I don't understand.
An example for America/New York seems to point to an area 115. There then seem to be multiple 115 entries like the following;
115, 3907893600, -18000, EST, 0 115, 3919388400, -14400, EDT, 1
My interpretation is that 115 is the area, the next column should be some sort of latitude, next seems to be called an offset in other contexts, next is the used name of the zone followed by a true/false bit.
*My* guess is that 115 is some representation of an area, 3907893600 is some representation of a time when the US Eastern time zone switches to Standard time, -18000 is the offset in seconds from UTC to use for the time zone after that time, "EST" is the abbreviation to use for the time zone after that time, and 0 is a "Daylight Savings Time is not in effect" indication.
I.e., if you sort all the entries for a given area by the second field, it's a list of standard <-> {daylight savings, summer} time transitions, with each entry saying when the transition occurs, what the offset from GMT in seconds is after that transition, what the zone abbreviation is after that transition, and whether you're in standard or {summer, daylight savings} time after that transition.
You don't need to know all the politics and states, but you do need to have bounding polygons for each zone area. I am not aware of a source of this information (if anyone else does, I'd like to know, as it would be useful to me too). In many areas it is straightforward if tedious to research and create this, but if you go to out of the way places you'll probably end up guessing quite a bit of it! If you are just looking at current dates, then you can probably simplify the database quite a lot, as many zones exist to cover historical variations. Also, time data does vary with depressing regularity, so you will need to look at updating your database. Tim Smartcom Software Ltd Portsmouth Technopole Kingston Crescent Portsmouth PO2 8FA United Kingdom www.smartcomsoftware.com Smartcom Software is a limited company registered in England and Wales, registered number 05641521. -----Original Message----- From: Larry Ober [mailto:larry.ober@att.net] Sent: 03 February 2011 18:33 To: tz@lecserver.nci.nih.gov Subject: lat/lon to time offset database I'm a nubie at understanding the ins and outs of timezones so please forgive me for my potentially dumb questions. 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". I don't really need the geo political information like country or city. However it seems like tz is structured continent/country/city/... Now maybe I already have what I need but I just don't understand it. I have a copy of timezone.csv that seems to include data from country code to city etc. This seems to point to what looks like coordinate data that I don't understand. An example for America/New York seems to point to an area 115. There then seem to be multiple 115 entries like the following; 115, 3907893600, -18000, EST, 0 115, 3919388400, -14400, EDT, 1 My interpretation is that 115 is the area, the next column should be some sort of latitude, next seems to be called an offset in other contexts, next is the used name of the zone followed by a true/false bit. If this is basically true, I guess that what I don't understand it how to "parse" the latitude and how to use the longitude offset. Of course maybe I have this entirely wrong. I would appreciate any help on this basic issue. Regards Larry
On Thu, Feb 3, 2011 at 10:33, Larry Ober <larry.ober@att.net> wrote:
I don't really need the geo political information like country or city. However it seems like tz is structured continent/country/city/..
As others have said, you do need the geo-political information. And even that may not be sufficient. There's a region in China where some people use Beijing time and others use local time. Search in the TZ mailing list archives for Xinjiang and Urumqi. One email renewing the discussion was dated May 2010. The rest of the discussion (under a different subject which I haven't located in my archive, mainly for not looking hard enough) pre-dates that. The upshot is though that even with a GPS database, you can't tell whether the wielder of the GPS-equipped system would prefer Beijing or Xinjiang time in that vicinity; it depends on who the wielder is. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
On Feb 3, 2011, at 4:43 PM, Jonathan Leffler wrote:
On Thu, Feb 3, 2011 at 10:33, Larry Ober <larry.ober@att.net> wrote: I don't really need the geo political information like country or city. However it seems like tz is structured continent/country/city/..
As others have said, you do need the geo-political information. And even that may not be sufficient.
There's a region in China where some people use Beijing time and others use local time. Search in the TZ mailing list archives for Xinjiang and Urumqi. One email renewing the discussion was dated May 2010. The rest of the discussion (under a different subject which I haven't located in my archive, mainly for not looking hard enough) pre-dates that.
The upshot is though that even with a GPS database, you can't tell whether the wielder of the GPS-equipped system would prefer Beijing or Xinjiang time in that vicinity; it depends on who the wielder is.
True. I think that that's a one of a kind case, though. paul
On 02/03/11 13:53, Paul Koning wrote:
I think that that's a one of a kind case, though.
China is a one-of-a-kind case? It's a pretty big case! But it's not the only case, I'm afraid. Major disputes often bleed over into minor disputes about clocks. For example, in the West Bank I expect that while most inhabitants prefer Palestinian DST rules, some prefer Israeli.
On 3 Feb 2011, at 21:53, Paul Koning <paul_koning@Dell.com> wrote:
On Feb 3, 2011, at 4:43 PM, Jonathan Leffler wrote:
The upshot is though that even with a GPS database, you can't tell whether the wielder of the GPS-equipped system would prefer Beijing or Xinjiang time in that vicinity; it depends on who the wielder is.
True. I think that that's a one of a kind case, though.
You should read David Prerau's book about DST which is quite entertaining and has many examples of utter TZ confusion in the USA in the mid 20th C. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/
On Feb 4, 2011, at 5:43 AM, Jonathan Leffler <jonathan.leffler@gmail.com> wrote:
The upshot is though that even with a GPS database, you can't tell whether the wielder of the GPS-equipped system would prefer Beijing or Xinjiang time in that vicinity; it depends on who the wielder is.
I am relieved to hear though from a later post that GPS manufacturers still provde for you to manually enter your desired time zone, (Xinjiang time still sadly an orphaned child of the digital world.) Luther PS I would be happy to open the discussion of XJ time again, or likewise to accept any previous suggestion without further objection.
On 03/02/2011 18:33, Larry Ober wrote:
I'm a nubie at understanding the ins and outs of timezones so please forgive me for my potentially dumb questions.
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".
I had a go at doing this a few years ago when I was creating the earthtools.org website. I thought like you that it would be fairly straightforward, but no, it's really not! The result is accessed by webservice through earthtools.org, but the data is a few years old now and it's not really that accurate. I basically generated a map of the zones as accurately as I could (limited by not having accurate administrative area boundaries) and did some processing to reduce the complexity of lookups. I blogged about it 5 years ago: http://blog.jstott.me.uk/2005/12/01/mapping-time-zones/ and http://blog.jstott.me.uk/2005/12/08/time-zone-map-completed/ If anyone has any ideas for how to improve the accuracy or, more importantly, map daylight savings time rules (which are even more complicated), I'd love to know! Jonathan
On Feb 3, 2011, at 6:16 PM, Jonathan Stott wrote:
On 03/02/2011 18:33, Larry Ober wrote:
I'm a nubie at understanding the ins and outs of timezones so please forgive me for my potentially dumb questions.
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".
I had a go at doing this a few years ago when I was creating the earthtools.org website. I thought like you that it would be fairly straightforward, but no, it's really not! The result is accessed by webservice through earthtools.org, but the data is a few years old now and it's not really that accurate.
Is this a system for Internet users ? If so, I have to wonder if it would be more efficient to add this to the IP geolocation databases, which map IP addresses to locations. These are not perfect, but they are pretty good, and they don't require a finite element map of the major rivers and geopolitical border on the planet. Regards Marshall
I basically generated a map of the zones as accurately as I could (limited by not having accurate administrative area boundaries) and did some processing to reduce the complexity of lookups. I blogged about it 5 years ago: http://blog.jstott.me.uk/2005/12/01/mapping-time-zones/ and http://blog.jstott.me.uk/2005/12/08/time-zone-map-completed/
If anyone has any ideas for how to improve the accuracy or, more importantly, map daylight savings time rules (which are even more complicated), I'd love to know!
Jonathan
Thanks Jonathan. It seems to work pretty well. Larry ----- Original Message ----- From: "Jonathan Stott" <jonathan@jstott.me.uk> To: <tz@lecserver.nci.nih.gov> Sent: Thursday, February 03, 2011 6:16 PM Subject: Re: lat/lon to time offset database
On 03/02/2011 18:33, Larry Ober wrote:
I'm a nubie at understanding the ins and outs of timezones so please forgive me for my potentially dumb questions.
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".
I had a go at doing this a few years ago when I was creating the earthtools.org website. I thought like you that it would be fairly straightforward, but no, it's really not! The result is accessed by webservice through earthtools.org, but the data is a few years old now and it's not really that accurate.
I basically generated a map of the zones as accurately as I could (limited by not having accurate administrative area boundaries) and did some processing to reduce the complexity of lookups. I blogged about it 5 years ago: http://blog.jstott.me.uk/2005/12/01/mapping-time-zones/ and http://blog.jstott.me.uk/2005/12/08/time-zone-map-completed/
If anyone has any ideas for how to improve the accuracy or, more importantly, map daylight savings time rules (which are even more complicated), I'd love to know!
Jonathan
Larry Ober <larry.ober <at> att.net> writes: Well this has certainly been educational. Thanks to all of you for your input. I now have a lot to think about. Best Regards Larry
Looks like you've got this resolved but I thought I'd add my experience. Timezones are political, not geographical. They change all the time, they are not static. I manage the data feeds to our "how and when to listen" web site for the BBC World Service. We map from population centre to timezone name using Geonames and from timezone name to offset using Olson. Cheers Julian -----Original Message----- From: Larry Ober [mailto:larry.ober@att.net] Sent: 03 February 2011 18:33 To: tz@lecserver.nci.nih.gov Subject: lat/lon to time offset database I'm a nubie at understanding the ins and outs of timezones so please forgive me for my potentially dumb questions. 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". I don't really need the geo political information like country or city. However it seems like tz is structured continent/country/city/... Now maybe I already have what I need but I just don't understand it. I have a copy of timezone.csv that seems to include data from country code to city etc. This seems to point to what looks like coordinate data that I don't understand. An example for America/New York seems to point to an area 115. There then seem to be multiple 115 entries like the following; 115, 3907893600, -18000, EST, 0 115, 3919388400, -14400, EDT, 1 My interpretation is that 115 is the area, the next column should be some sort of latitude, next seems to be called an offset in other contexts, next is the used name of the zone followed by a true/false bit. If this is basically true, I guess that what I don't understand it how to "parse" the latitude and how to use the longitude offset. Of course maybe I have this entirely wrong. I would appreciate any help on this basic issue. Regards Larry http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
participants (28)
-
Alois Treindl -
Bill Seymour -
Chris Walton -
Clive D.W. Feather -
David Patte -
Dirkjan Ochtman -
Garrett Wollman -
Guy Harris -
Hjwoudenberg -
Ian Abbott -
John Haxby -
Jonathan Leffler -
Jonathan Stott -
Julian Cable -
Larry Ober -
Luther Ma -
Mark Davis ☕ -
Marshall Eubanks -
mxtaylor@ups.com -
O'Neil, Bonnie -
Paul Eggert -
Paul Koning -
Paw Nielsen -
Peter Seo -
Robert Elz -
Tim Thornton -
Tony Finch -
yoshito_umaoka@us.ibm.com