Time Zone Boundaries

General talk
8

Hello, I’m the maintainer of timezone-boundary-builder and I thank @Minh_Nguyen for bringing this thread to my attention.

I’d like to add my thoughts here on several items.

Quality and Comprehensive Coverage

Since this topic first started years ago, the quality of timezone relations in OpenStreetMap has improved dramatically as a result of my and Arctic Gnome’s edits. As of today, 94.5% of the 419 timezone IDs from the timezone database’s zone.tab file are mapped in OpenStreetMap in a manner where a single Overpass query for all relations with a timezone=* tag are able to be downloaded and unioned into a GeoJSON multipolygon. Most of the remaining ones are zones in Antarctica that haven’t yet been mapped.

This data has been relied upon since the timezone-boundary-builder project started in 2016. However over time and especially in the last year I made an effort to add and correct as many boundaries as possible in OpenStreetMap. It is no longer a “futile effort” to map timezones as the coverage is mostly complete across the globe. It still does take some effort to keep things current, but that effort takes me a few hours a few times a year.

Usage of timezone data

The timezone-boundary-builder project has had over 300,000 downloads of release data since its inception. There are currently 21 known software packages in various programming languages that use this data. Some of these packages have several million downloads such as the python package timezonefinder which has over 1 million monthly downloads.

Given the widespread usage of this data, I recommend caution before considering any deletion of this data.

Preference for continued inclusion of timezone boundaries in OSM, not OHM

While the timezone-boundary-builder project is capable of making numerous queries for various relations and ways-as-areas, I don’t believe it is appropriate for inclusion in OHM. New timezones are only created through the timezone database project when there is an area of the world that has a timekeeping method that uniquely diverges from any other timekeeping methods. Therefore any query to get the historical time at a given GPS coordinate needs the current boundaries of timezones. Additionally, it would be a significant amount of effort to go back to manually compiling boundaries from all of the relations that make up some timezone boundaries without simply querying for the timezone=* tag.

Another item to consider is that the timezone database only keeps track of time changes occurring after the year 1970 as noted in the theory page. Therefore, OHM may need to use a different and not as widely-used data source to account for time changes before 1970.

Large UTC* timezone relations

I am aware of the large timezones that Arctic gnome is creating that are of the UTC* variation. These large relations are not used in timezone-boundary-builder. Instead of downloading large relations from OSM, timezone-boundary-builder simply diffs against all other timezones to create zones in the oceans.

While I do not know Arctic gnome's intent with creating these large relations I don’t think they present a problem to the data being used in timezone-boundary-builder either. It does seem that they don’t necessarily fit into the scope of what is described in the boundary=timezone or Key:timezone wiki pages.

Desired clarifications/discussion

Instead of simply calling for a mass deletion of data, I urge this conversation to steer more towards what policies we should be implementing when mapping timezones. Since the data exists and has existed for the better part of a decade now and is heavily used, I would be surprised if this data were to suddenly be deleted.

However, I do think some discussions would be useful to have as it relates to how to map timezone boundaries as it pertains to the following topics:

  • Whether or not it’s appropriate to include the UTC* timezones that Arctic gnome has been adding.
  • Whether or not it’s appropriate to include Exclusive Economic Zones within the boundaries of timezones
  • How to handle discrepancies between various “deprecated” timezones. For this one, the maintainer of the timezone database keeps some timezones that share the same timekeeping method since 1970, but have differed prior to that cutoff year. In the past there was not such cutoff and a significant amount of commotion occurred after the maintainer instituted the 1970 cutoff.

Etcetera

Creating relations for time zones would be generally unnecessary since
no place is in two time zones at once.

  1. There are plenty of places where a relation is needed to model a timezone. There are lots of places where a timezone boundary does not follow any administrative boundary. The boundary between America/Chicago and America/Denver in particular has plenty of places where the boundary goes along a river, a road and sometimes arbitrary surveying points.

  2. There are numerous places where a single place can be in multiple timezones at once. The largest example is Asia/Urumqi, but also any place where there is also a border dispute will also result in multiple possible timezones. Also, people that live near timezone boundaries will often informally use a different timekeeping method despite being in an area that otherwise sometimes resulting in interesting situations like in Fort Pierre, North Dakota.

2 Likes