[tz] Fixing GeoNames timezone error

Chris Walton crj.walton at gmail.com
Fri Jul 8 00:11:16 UTC 2022

The Nipigon/Toronto is a pet peeve of mine.
It is the result of some questionable data inside Openstreetmap (OSM).

Nipigon is a small township in Northern Ontario with a population of 1473
and an area of 108 square km.
To put this into perspective:
-Nipigon contains 0.01% of Ontario's total population.
-Nipigon makes up 0.01% of Ontario's total land area.

Inside OSM,  somebody moved 73% of the land in Ontario into the
*America/Nipigon* timezone.  It was done with about 120 separate changesets
between February and June of 2020.  Some of the changesets have no source;
others list "Shanks" as a reference.
After following this mailing list for 15 years, I am very skeptical of the
work published by Shanks, but I am in no position to prove it is wrong.
I am also skeptical that anybody travelling directly by car from Windsor to
Montreal (post 1970) would have had to pass through multiple time zone

The OSM relations are listed below.
Note that if you click on the OSM links, the colour orange is used for both
inner and outer boundaries thus the inner polygons are "holes" or "excluded
areas". Without shading, it is not always simple to recognize this.
The relations are large and may take some time to load in your browser.

OSM America/Toronto relation:
 Includes most of Quebec and most urban centres in Ontario.
 Area: 1,546,844.1 square km.

OSM America/Nipigon relation:
 Includes most rural areas of Ontario east of 90°W
 Also includes a few populated centers such as Sarnia (pop: 72,047) and
Barrie (pop: 147,829).
 Area: 787,493.2 square km.

>From a daylight saving standpoint, both zones have been the same since 1974.

It would be very helpful if somebody could accurately determine when Barrie
and Sarnia started using daylight saving (without using Shanks or OSM as a


On Thu, 7 Jul 2022 at 15:11, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20220707/6540b692/attachment.htm>

More information about the tz mailing list