Per [e-mail] message, odd behavior with America/Nigipon vs. America/Toronto

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]

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.

[crjwalton]

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.