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

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

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

<<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 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

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.

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.

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.

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.

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.

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 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

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 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.

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.

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 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 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