Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Per [email protected] message, odd behavior with America/Nigipon vs. America/Toronto #131

Closed
kshetline opened this issue Jul 7, 2022 · 25 comments
Closed

Per [email protected] message, odd behavior with America/Nigipon vs. America/Toronto #131

kshetline opened this issue Jul 7, 2022 · 25 comments

Comments

@kshetline
Copy link

Using the example of Walpole Island, Ontario, when I try to find a timezone shape which contains the lat/long of this location (42.6152, -82.51398), I oddly get a match for America/Nigipon rather than America/Toronto (at least it’s not America/Detroit, as GeoNames has it). I get several matches, in fact, for America/Nigipon that don’t make sense, given that this zone should have a very small area.

I’m using the @turf/turf npm library to parse the shape files, and booleanPointInPolygon() to check if a particular zone contains a specific lat/long point.

You can see where I do this in the function findTimezone(), in the following code, currently at line 79: https://github.com/kshetline/geo-db-updater/blob/development/src/app.ts

The logic of this code is based on reducing the number of zones I check by breaking the world up into 15°x15° chunks, and checking only the shapes of timezones with bounding rectangles overlapping those 15°x15° areas.

When checking Walpole Island, I end up checking these zones: America/Chicago, America/Detroit, America/Indiana/Indianapolis, America/Indiana/Knox, America/Indiana/Marengo, America/Indiana/Petersburg, America/Indiana/Tell_City, America/Indiana/Vevay, America/Indiana/Vincennes, America/Indiana/Winamac, America/Kentucky/Louisville, America/Kentucky/Monticello, America/New_York, America/Nipigon, America/Toronto

I tried reversing the order I check these zones in, so that I checked America/Toronto before checking America/Nipigon, but even then (42.6152, -82.51398) was found in America/Nipigon, and not in America/Toronto.

The problems with these two zones aren't unique either. I get odd results using this search/match technique all over the globe.

The fault, of course, could be in my own logic, or in @turf/turf, and not in your zone definitions.
@evansiroky
Copy link
Owner

I'm adding a reference to the tz mailing list discussion about this.

In the mailing list discussion, I agree with the comment made by Chris Walton that I am skeptical of the America/Nipigon tz relation in OSM, but also am in no position to prove that a part or a whole of it is wrong.

@evansiroky
Copy link
Owner

I've sent a message to the OSM user Arctic gnome to request their input. I believe they have made most of these edits to the America/Nipigon and America/Toronto timezones.

@kshetline
Copy link
Author

Going by this web site: https://www.distancesto.com/time-zones/america/nipigon.html

...America/Nipigon should be a very small, nearly rectangular region.

America-Nipigon-1

America-Nipigon-2

It has a fairly simple definition:

{
  "type": "FeatureCollection",
  "crs": {
    "type": "name",
    "properties": {
      "name": "urn:ogc:def:crs:OGC:1.3:CRS84"
    }
  },
  "features": [
    {
      "type": "Feature",
      "properties": {
        "TZID": "America/Nipigon"
      },
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [-88.23448491923624, 48.952994735358004],
            [-88.23487091064453, 48.953041076660156],
            [-88.24162292480469, 48.9555549621582],
            [-88.24617004394531, 48.9595947265625],
            [-88.25310516357422, 48.97331619262696],
            [-88.25745391845703, 48.992679595947266],
            [-88.25802612304688, 48.995201110839844],
            [-88.25543212890625, 49.00632095336914],
            [-88.25821685791016, 49.01075744628906],
            [-88.26227569580078, 49.0076904296875],
            [-88.26441955566406, 48.9979248046875],
            [-88.26039123535156, 48.98247528076172],
            [-88.26238250732422, 48.97911071777344],
            [-88.2685546875, 48.97565841674805],
            [-88.2708740234375, 48.972530364990234],
            [-88.2618408203125, 48.9589729309082],
            [-88.2609177591477, 48.95022140807116],
            [-88.26239687003915, 48.95244384292245],
            [-88.43281365961772, 48.95277603939336],
            [-88.43299780563895, 49.03916948894521],
            [-88.23623908787941, 49.039253898519554],
            [-88.23448491923624, 48.952994735358004]
          ]
        ]
      }
    }
  ]
}

The definition from evansiroky/timezone-boundary-builder is comparatively huge, and covers much more territory, at least from what I see in the numbers. (I don't know where to find a visualizer for this data, but I'd appreciate a recommendation.)

@kshetline
Copy link
Author

I found a (very slow!) visualizer to check what the evansiroky/timezone-boundary-builder version of America/Nipigon looks like, and it's very different:

America-Nipigon-3

Both versions of America/Toronto are also very different:

America-Toronto-1

America-Toronto-2

The distanceto.com definitions seem to make a lot more sense to me.

@kshetline
Copy link
Author

kshetline commented Jul 8, 2022 •
edited
Loading

I take back what I said about the distancesto.com definitions making more sense. Montreal should be inside America/Toronto, but isn't. The distancesto.com site even says (verbally) that Montreal is in America/Toronto, but graphically is isn't.

@kohenkatz
Copy link

In the Wikipedia article on Time in Canada, there is this note on America/Toronto:

Legally includes all of Ontario east of 90th meridian west, but in practice only applied to urban areas until 1974.

It provides no source for this statement, but I'm guessing that Shanks is probably the origin of it.

In any case, the implication is that in most of this area the government would have used the America/Toronto definition that includes DST but the locals would have used the America/Nigipon definition that does not include DST.

@crjwalton
Copy link

Yes; Shanks is certainly the origin of this mess. It is possible that there were a few holdouts in rural Ontario east of of 90°W that did not adopt daylight saving until 1974. However, we know that Shanks made up some of his data. Even for the township of Nipigon itself, I am not convinced that Shank's data should be trusted.

For what it is worth, the Canadian Pacific train schedule from the summer of 1970 places all railway stops between Thunder Bay and Montreal on "Eastern Time". "Eastern Daylight Time" is implied. I looked at the the time and distance deltas between stations. The train travelled at roughly 40MPH and there are no anomalies where the trains suddenly gain or lose an hour.

As I posted in the TZ mailing list last night, the current America/Nipigon relation in Openstreetmap consumes 73% of the land in Ontario. I think it is ridiculous given the nature of the data source.

I see two valid options:

  1. reduce the boundary of America/Nipigon to match the township of Nipigon.
  2. eliminate America/Nipigon due to lack of credible sources; this would require discussions on the TZ mailing list.
    With either option, America/Toronto would need to be expanded to fill the void.

-chris

@kshetline
Copy link
Author

Going back for many years (to 1975?), America/Nipigon, America/Toronto, America/Detroit, and America/New_York have all been functionally the same it seems, so perhaps the distinctions all come down to some fuzzy history, after which any of these zones yields the correct results?

@kshetline
Copy link
Author

kshetline commented Jul 9, 2022 •
edited
Loading

I'd guess from the other comments I've read here that reducing America/Nipigon down to the boundaries used by distancesto.com, and giving the rest back to America/Toronto, makes the most sense.

I've also emailed distancesto.com about the error of leaving all of Quebec out of their version of America/Toronto.

@crjwalton
Copy link

kshetline,
I am not sure how you found anything at distanceto.com. The main website says the domain is for sale.
Regardless, there used to be a dedicated zone in the TZ database named "America/Montreal". It got turned into a link a number of years ago. Some time zone maps may continue to to maintain a polygon named America/Montreal that includes most of Quebec. It would not be a crime to do so. This may explain why you found a map that excludes Quebec from America/Toronto.
-chris

@kshetline
Copy link
Author

kshetline, I am not sure how you found anything at distanceto.com.

Sorry about that! distancesto.com - I accidentally left out the second 's'. I've fixed the typo in my previous comments.

@ArcticGnome
Copy link

Hi, I'm Arctic_gnome.

I expanded America/Nipigon based on Shanks International Atlas. It names hundreds of villages in Canada along with the date any of them started DST or switched time zones. It every direction, I looked up neighbouring villages until I hit one where it no longer matched America/Nipigon's history of starting DST in 1974.

The result is the huge version of the America/Nipigon zone as seen on OSM: https://www.openstreetmap.org/relation/6498592. According to Shanks, most of Ontario didn't start using DST until 1974. Only the areas around larger population centres follow America/Toronto's example of starting DST before the Unix time epoch.

From a purely legal point of view, I'm skeptical of whether America/Nipigon or America/Thunder_Bay ever existed. I've been looking at Ontario laws from the 1970s, and I so far I can't find any provision that would grant municipalities authority to opt out of daylight savings time (I'd need to access a good law library to know for sure).

But regardless of the law, there seems to be enough evidence to show that, in practice, not all of Ontario used daylight savings from 1970-1974. I've seen scans of newspapers from the 1970s mention it. It also lines up with what I was told by older folks in North Ontario: that small communities north of Greater Toronto resisted DST for decades.

It's possible that Shanks is wrong about how far America/Nipigon reaches. The atlas doesn't give a methodology for how it determined when each of these communities started using DST. Many of the little Hamlets mentioned in Shanks don't even have municipal governments, and therefore have no bylaws to look up. The only way Shanks could have known the date of time change for these tiny hamlets is if they talked to locals.

If Shanks is wrong, we need to find another source to determine which communities used DST in the early 1970s and who didn't. I think Crjwalton had a good idea to use railway schedules. With respect to Kshetline, I advise against using the boundary from Google, because that probably wasn't the boundaries in 1970-1974. Does anyone know what source was used when America/Nipigon and America/Thunder_Bay were first added to the tz Database?

@crjwalton
Copy link

ArcticGnome,

  1. No, I don't believe that Ontario ever granted official exceptions to opt out of daylight saving. At the same time, it never enforced the rules. e.g. the town of Atikokan has been on permanent EST since WWII even though Ontario's rules dictate it is supposed to be on CST/CDT.
  2. If we use train schedules, then the size of America/Nipigon will immediately shrink to zero. That could be a good thing or a bad thing depending on how you look at. The schedule I was looking at can be found here: https://streamlinermemories.info/CAN/CP70-4TT.pdf.
  3. Many contributors to the TZ database have found errors in Shanks data. It was concluded at some point a few years ago that a lot of his data was fake. This should not be surprising because realistically it would take multiple lifetimes to gather accurate data from all the small towns in the world. I don't deny that some places may have resisted using daylight saving until 1974, but I question whether boundaries in OSM should be based off data that may be partly fake.
  4. As I wrote on the TZ mailing list, I very much doubt that travelers had to pass though multiple time zone regions when travelling by car from Windsor to Montreal (post 1970). 1970 is important because that is the cutoff date in the TZ database. An area is only given a unique time zone ID if it has differed from all other areas at any time after 1970. The zone America/Nipigon should not exist if it can be proven that it has shared the same time as Toronto since 1970.
  5. This map shows the boundaries of Nipigon Township Municipality and Red Rock Township Municipality. https://geohub.lio.gov.on.ca/datasets/municipal-boundary-lower-and-single-tier/explore?location=48.988001%2C-88.288496%2C10.58
  6. This map shows the improved geographic township of Nipigon. https://geohub.lio.gov.on.ca/datasets/lio::geographic-township-improved/explore?location=48.972690%2C-88.291379%2C10.58
  7. I believe that the two maps I listed above can be found in Shapefile or KML format somewhere, but I am not digging them up tonight.
  8. The time zone rules in the TZ database for America/Thunder_Bay and America/Nipigon are unfortunately based off of Shanks data. I am not convinced that the rules for Thunder Bay are correct.
  9. The current OSM relation for America/Nipigon includes Prince Edward County and Wolfe Island. I visited these places many times as a child and never ever experienced a time change.
    -chris

@ArcticGnome
Copy link

That all makes sense to me. If law says America/Nipigon, America/Thunder_Bay, and America/Atikokan don't exist, I think we should default to shrinking them to zero, and only give them size if someone finds clear evidence that a certain place didn't follow DST. And for this purpose, Shanks does not count as proof.

@crjwalton
Copy link

ArcticGnome,
Sorry I was away for a few days.

America/Atikokan is valid; please do not remove it from OSM. Back in 2006 I had an e-mail exchange with Warren Paulson who was the Chief Administrative Officer for the Township of Atikokan. He told me that Atikokan had been using Eastern Standard Time (with no daylight saving) since at least 1952. I am not sure if I still have the old e-mail thread, but I did post the relevant info on the TZ mailing list: https://mm.icann.org/pipermail/tz/2006-July/013730.html. The OSM boundary for America/Atikokan is based on a KML file I published on the web in 2007; the boundary includes Quetico Provincial Park which is administered out of the town of Atikokan.

America/Thunder_Bay and America/Nipigon need further discussion on the TZ mailing list. I will try and post something there in the next day or two.
-chris

@ArcticGnome
Copy link

ArcticGnome commented Jul 13, 2022 via email

@szjozsef
Copy link

After this timezones was removed from OSM, in order to be able to build the timezone-boundary's again this timezones has to be removed from the config files, the removed areas are covered by:
America/Winnipeg and America/Toronto
The removed objects from: timezones.json

  "America/Nipigon": [
    {
      "op": "init",
      "source": "overpass",
      "id": "America-Nipigon-tz"
    }
  ],
  "America/Rainy_River": [
    {
      "op": "init",
      "source": "overpass",
      "id": "America-Rainy_River-tz"
    }
  ],
  "America/Thunder_Bay": [
    {
      "op": "init",
      "source": "overpass",
      "id": "America-Thunder_Bay-tz"
    }
  ],

The removed objects from: osmBoundarySources.json

  "America-Nipigon-tz": {
    "timezone": "America/Nipigon"
  },
  "America-Rainy_River-tz": {
    "timezone": "America/Rainy_River"
  },
  "America-Thunder_Bay-tz": {
    "timezone": "America/Thunder_Bay"
  },

@ArcticGnome
Copy link

ArcticGnome commented Aug 26, 2022 via email

@jannikmi jannikmi mentioned this issue Sep 27, 2022
Closed
@jannikmi
Copy link

For future reference: The GUI I have built for the python package timezonefinder (internally using timezone-boundary-builder data) can be used for visualising the timezone polygons.
E.g. https://timezonefinder.michelfe.it/gui/0_-82.70507812500001_47.2195681123155

@danipozo danipozo mentioned this issue Oct 12, 2022
Closed
@crjwalton
Copy link

crjwalton commented Oct 18, 2022 •
edited
Loading

On October 15, 2022, three northern Ontario zones were converted from dedicated "Zones" to "Link" entries in the GitHub repository for the TZ database. The new Link entries look like this:
America/Thunder_Bay --> America/Toronto
America/Nipigon --> America/Toronto
America/Rainy_River --> America/Winnipeg
The changes will be included in the next release (likely to be named 2022f).

Justification for the changes were:

  1. The data for America/Thunder_Bay contained an error for the year 1973. With that error fixed, it is now believed that Thunder Bay has been in sync with Toronto since the beginning of the UNIX epoch (Jan 1, 1970).
  2. The data for America/Nipigon was proven to be incorrect for the year 1972. The data for 1970 and 1971 remains questionable.
  3. The data for America/Rainy_River was considered to be questionable simply because it was derived from the same error ridden sources as the other two zones.

It is possible that America/Nipigon or America/Rainy_River could be revived in the future; somebody would need to prove (without using Shanks based data) that they have not been the same as Toronto and Winnipeg since 1970.

For now, all three of the above mentioned northern Ontario zones should be considered as deprecated.

@ArcticGnome
Copy link

ArcticGnome commented Oct 18, 2022 via email

@crjwalton
Copy link

ArcticGnome,
The Thunder Bay Public Library recently sent me newspaper scans with daylight saving announcements for 1973. They provide proof that Thunder Bay did observe daylight saving in 1973.
I posted a summary (with the newspaper scans attached) on the TZ mailing list:
https://mm.icann.org/pipermail/tz/2022-October/032063.html
There are links to the scanned images (pdf files) at the bottom of the post.

@crjwalton
Copy link

ArcticGnome,
Also... I don't know exactly what weather station data you were looking at. If the raw weather data has undergone any conversion between UTC and local time, that conversion would almost certainly have been done with data from the TZ database. This could very likely explain why the weather data shows no daylight saving for 1973.
I tend to prefer printed newspaper articles over other sources of data because they are immune to modern data manipulation.

evansiroky added a commit that referenced this issue Oct 25, 2022
@evansiroky
Revert to manual OSM definitions for a few Canada zones
5593501 
Refs #131
@evansiroky
Copy link
Owner

All, I really appreciate the continued discussion here. I had a lapse of motivation for a few months, so I had to publish something to get this project somewhat current. I see that there are already some unreleased changes in the tz database, so I'll be sure to get those into another release once the tzdb releases those changes.

@evansiroky
Copy link
Owner

As @crjwalton predicted, 2022f has been released with these changes, so I'll be making a new release shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@kohenkatz @evansiroky @jannikmi @szjozsef @kshetline @ArcticGnome @crjwalton