I wonder if Geonames.org updated to use the new data yet? On Sun, Nov 8, 2015 at 6:19 PM, Mark Davis ☕️ <mark@macchiato.com> wrote:

Very nice!

Mark

On Sun, Nov 8, 2015 at 10:31 AM, Eric Muller <eric.muller@efele.net> wrote:

...

I have updated the efele.net/tz maps (http://efele.net/maps/tz/) to be in sync with TZ 2015g. The new zones:

Pacific/Bougainville Asia/Chita Asia/Srednekolymsk America/Fort_Nelson Antarctica/Troll

Eric.

Eric M., Matt is correct. You should adjust your map such that the northern boundary of America/Dawson_Creek aligns with the northern boundary of the Peace River Regional District (PRRD). This is a map that I created back in 2011; I shared it on this same mailing list at the time. http://maps.google.com/maps/ms?ie=UTF&msa=0&msid=212137821026080676505.00049... The green area represents the entire Peace River Regional District (PRRD). The red outline represents my definition of the Peace River time zone area (a.k.a. America/Dawson_Creek). Questions have recently been asked about the western boundary for America/Dawson_Creek. Specifically, Steve Jones recently asked me in a separate e-mail why my map does not extend the Peace River time zone area (America/Dawson_Creek) west to include the entire PRRD. Steve apparently had a conversation with the GIS Coordinator for the PRRD; Steve was told that “full MST applies to the entire PRRD”. I do not agree with the statement that full MST (year-round Mountain Standard Time) applies to the entire PRRD. There is one (and only one) community in the western half of the PRRD; it is the isolated community of Fort Ware (also known as Kwadacha). It has a population of about 270. Wikipedia states that Mountain Time is observed year-round in “most of Peace River Regional District (except Fort Ware)”. https://en.wikipedia.org/wiki/Time_in_Canada#Mountain_Time_Zone I phoned the Kwadacha Nation Band Office today. The office is located in Fort Ware. I spoke with a lady who told me that Fort Ware keeps the clocks in sync with Vancouver (PST/PDT). Wikipedia is therefore correct. When I created my map in 2011, I drew the time zone boundary though the Muskwa and Hart mountain ranges; that correctly put Fort Ware on the west side of the boundary and all other communities in the PRRD on the east side. https://en.wikipedia.org/wiki/Muskwa_Ranges https://en.wikipedia.org/wiki/Hart_Ranges I used topographical maps to try and keep the line running right along the watershed boundaries. The watershed boundaries are (by definition) always high up in the mountains where few people venture. I don’t see any reason to make any changes to my map. People are still free to use it, copy it, or ignore it as they see fit! And for those that are interested: Fort Ware is one of the most remote Canadian communities outside of the Artic. The only land based connection to rest of the world is a 400km logging road that takes 8 to 10 hours to navigate. I cannot say I have ever made the trip myself. -chris From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Matt Johnson Sent: November 8, 2015 08:20 PM To: Zoidsoft Cc: tz@iana.org Subject: Re: [tz] efele.net/tz maps updated Yes, many thanks Eric! Though I think there's a slight correction needed for to extend the America/Dawson_Creek north to America/Fort_Nelson boundary, per Chris Walton: https://mm.icann.org/pipermail/tz/2011-March/016744.html @Zoidsoft - It's not clear whether Geonames uses Eric's tz maps or not, but either way it isn't yet reporting correctly for America/Fort_Nelson: http://api.geonames.org/timezoneJSON?lat=58.80533&lng=-122.7002&username=dem... Currently it returns America/Vancouver. So does Google: https://maps.googleapis.com/maps/api/timezone/json?location=58.80533,-122.70... There's a list of similar offerings here: http://stackoverflow.com/questions/16086962/how-to-get-a-time-zone-from-a-lo... -Matt ________________________________ From: zoidsoft@gmail.com<mailto:zoidsoft@gmail.com> Date: Sun, 8 Nov 2015 19:24:45 -0500 CC: tz@iana.org<mailto:tz@iana.org> Subject: Re: [tz] efele.net/tz maps updated I wonder if Geonames.org updated to use the new data yet? On Sun, Nov 8, 2015 at 6:19 PM, Mark Davis [https://a.gfx.ms/emoji_02615.png] ️ <mark@macchiato.com<mailto:mark@macchiato.com>> wrote: Very nice! Mark On Sun, Nov 8, 2015 at 10:31 AM, Eric Muller <eric.muller@efele.net<mailto:eric.muller@efele.net>> wrote: I have updated the efele.net/tz<http://efele.net/tz> maps (http://efele.net/maps/tz/) to be in sync with TZ 2015g. The new zones: Pacific/Bougainville Asia/Chita Asia/Srednekolymsk America/Fort_Nelson Antarctica/Troll Eric.

On 11/29/2015 12:28 AM, L. David Baron wrote:

On Sunday 2015-11-08 10:31 -0800, Eric Muller wrote:

...

I have updated the efele.net/tz maps (http://efele.net/maps/tz/) to be in sync with TZ 2015g. The new zones: It's great to see this updated.

Thanks.

A few comments on the data:

(1) There are a few shapes in the maps that correspond to zones that are now links.

I started the maps while TZ still had a policy that a timezone would be "contained" in a political entity. When the great zone unification happened, I was faced with the choice to apply or not that unification to the maps. As it was a bit unclear where TZ would end up, and because it's easier to merge the shapes for those zones (it only takes data in TZ) than to split them (had I done the unification), I elected to retain as many zones as possible (see my message to this list on July 26, 2014). I took all the zone names that existed, rejected names like Etc/GMT+10, rejected names that are obviously aliases for the same geographical extent (eg Africa/Asmera, retaining Africa/Asmara), and kept all the others. It should be a trivial matter to take any equivalence relation on the zones and produce a map that has a single shape for each class. The equivalence relation could be "zones are linked", or "zones have the same local time over a given period of time".

(2) I noticed that the map uses the Sudanese claim for the border between Egypt and Sudan.

(3) When overlaying on other maps, I notice that the edges of the Aral sea are rather out-of-date.

Obviously, I could not come up with the TZ boundaries ex-nihilo. Because they mostly correspond to land and administrative boundaries, I had to start from an existing map that contains those boundaries. I also wanted a worldwide map, and the result to be as free as possible. The only/best dataset I could find is VMAP0. Unfortunately, that's a relatively old dataset and it has not been updated to account for changes in administrative boundaries. Another case is the Saudi Arabia/Yemen boundary. Arguably, I could try to fix those situations by injecting "better" data. Besides the inherent difficulty of that exercise (where do I get accurate data? how do I stitch it in?), it would also mean that my map could no longer be seen as an additional layer of the VMAP0 dataset. I did the best I could to facilitate the creation of a timezone map using another base dataset, by providing a logical description of the zones, and by publishing the script that relies mostly on FIPS 10-4 identifiers. May be it's time to move the effort to, e.g., OpenStreetMap?

(I've been playing with using the data to draw a "live" timezone map on the Web,

It would be cool to have a dual slider to select a time span for the map. Seeing a timezone as a function relating utc time and local time (over time), you can restrict those functions to a domain via the slider, and distinguish on the map only those functions which are distinct. Eric.

On Sunday 2015-11-29 09:31 -0800, Eric Muller wrote:

I started the maps while TZ still had a policy that a timezone would be "contained" in a political entity. When the great zone unification happened, I was faced with the choice to apply or not that unification to the maps. As it was a bit unclear where TZ would end up, and because it's easier to merge the shapes for those zones (it only takes data in TZ) than to split them (had I done the unification), I elected to retain as many zones as possible (see my message to this list on July 26, 2014). I took all the zone names that existed, rejected names like Etc/GMT+10, rejected names that are obviously aliases for the same geographical extent (eg Africa/Asmera, retaining Africa/Asmara), and kept all the others.

It should be a trivial matter to take any equivalence relation on the zones and produce a map that has a single shape for each class. The equivalence relation could be "zones are linked", or "zones have the same local time over a given period of time".

This sounds reasonable. It's not clear to me whether this is still accurate for China, though. It seems that the map data in http://efele.net/maps/tz/china/ are based on what is now described (I think) in the asia file in the tz source as being pre-1949 zones. These boundaries include areas in Asia/Urumqi (most suspiciously a few counties in Guangdong, and also parts of Qinghai and Gansu) that it's not clear to me are intended to be in Asia/Urumqi following the recent changes in https://github.com/eggert/tz/commit/15b01c042afa770acd5068054c50e7c5c663cbd2 which unify China's 5 zones into 2, and put Asia/Urumqi in UTC+6 rather than UTC+8 (along with Asia/Kashgar, which is now a link to Asia/Urumqi). When combined with the regions in your map data, this implies that Western Guangdong province (the counties of Xuwen, Haikang, Suixi, Lianjiang, Zhanjiang, Wuchuan, Huazhou, Gaozhou, Maoming, Dianbai, and Xinyi) is on UTC+6 today, and the same for western parts of Qinghai and Gansu (which seems more reasonable, but which I didn't see mentioned in the comments introduced in that commit). -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)