I'm reminded of the situation in Arizona with the Navajo and Hopi nations and adjacent towns, some of which have DST rules not necessarily in keeping with what you might expect for their locations: https://www.timeanddate.com/time/us/arizona-no-dst.html . There may be some other oddities in towns bordering Nevada and/or Idaho, IIRC. On Thu, Jul 7, 2022 at 12:11 PM Kerry Shetline via tz <tz@iana.org> wrote:
I’ll post a more detailed comment on GitHub later, and link to my own code where I’m trying to use your boundaries to solve some of these issues.
For the example of Walpole Island, Ontario, when I try to find a zone that contains the lat/long of this location, I oddly get the 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.
Evan Siroky <evan.siroky@yahoo.com> writes:
Hello, I'm the maintainer of? https://github.com/evansiroky/timezone-boundary-builder?which is a project that?extracts data from Open Street Map (OSM) to build shape files of the boundaries of the world's timezones. If you find inaccuracies with the data generated from this project, I'd love to know about these problems. Feel free to submit an issue in the GitHub project noting any problem that you see. Evan
-- Alan Mintz <Alan.Mintz@gMail.com>