[tz] Fixing GeoNames timezone errors

[dpatte]

I use the free geonames database in several of my projects. It is a user-contributed db, so all users are welcome to make corrections. They also have a paid version which is more heavily scrutinized for errors.


----- Original Message -----
 From: Kerry Shetline via tz [mailto:tz at iana.org]
 To: <tz at iana.org>
 Sent: Wed, 6 Jul 2022 15:50:02 -0400
 Subject: [tz] Fixing GeoNames timezone errors

 For those not familiar with the website, geonames.org provides a Creative Commons-licensed database of city, towns, geographic features, etc. Among other things, this DB provides latitude, longitude, and IANA timezone for millions of places around the world.

The problem is I’m finding many of the timezone values provided in this DB are incorrect. This mostly seems to be caused by places with coordinates near timezone boundaries being incorrectly assigned a nearby but incorrect timezone. For example, Walpole Island, Ontario, Canada, right next to the US border, is set to America/Detroit instead of the correct value of America/Toronto.

It’s at least easy to spot some errors like this, when a particular timezone is known to definitely belong to a different country, but there are many other errors at national, and state/province/prefect/etc. boundaries not so easy to spot. I was trying to create a timezone lookup based on country, state (admin level 1), and county (admin level 2) by going through the millions of entries in the database, building lists of which timezones were used where, but it quickly became apparent that the data was contaminated by many errors.

Does anyone know of a more reliable source for determining the timezone of a location on Earth, either by its latitude and longitude, or by the country and other administrative hierarchy information?

I’ve found downloads of shape files meant to define timezone boundaries, but they don’t seem to be very accurate. In fact, I suspect that the use of inaccurate timezone boundaries is the source of many of the errors in the Geonames DB, and that Geonames isn't even applying the help of the zone.tab file to rule out some of the errors caused by this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20220706/642811a9/attachment-0001.html>