[tz] Fixing GeoNames timezone error

[Alan Mintz]

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 at 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 at 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 at gMail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20220707/1492331d/attachment.html>