Zone Id is different from https://developers.google.com/maps/documentation/timezone/get-api-key about timeshape HOT 7 CLOSED

This problem looks like a recent change in these time zone coverage. As you probably know, Timeshape's data is taken from the https://github.com/evansiroky/timezone-boundary-builder/releases, which itself is derived from the OpenStreetMap. When I look at OpenStreetMap and query the Asia/Krasnoyarsk time zone, I get the result that largely agrees to google maps api: https://www.openstreetmap.org/relation/3563726#map=7/51.971/85.573. That is, your point (Gorno-Altaisk city) belongs to Asia/Krasnoyarsk time zone, and not to Asia/Barnaul like Timeshape suggests.

Now what that means is that the https://github.com/evansiroky/timezone-boundary-builder/ data doesn't match with the OpenStreetMap (anymore?). You could test this for yourself by downloading the current source data from https://github.com/evansiroky/timezone-boundary-builder/releases/tag/2020a, finding Asia/Barnaul and Asia/Krasnoyarsk time zones and plugging the corresponding data into some geojson visualizer, e.g. https://geojson.io. In case there's indeed a mismatch (which I suspect), you should raise this to the maintainer of timezone-boundary-builder.

from timeshape.

Great! Thank you! @RomanIakovlev.

from timeshape.

Hello, as I noted in evansiroky/timezone-boundary-builder#88, I believe that the data produced in timezone-boundary-builder is correct.

While the data in timezone-boundary-builder is derived from OSM, it is not simply fetched using overpass turbo queries for relations with timezone=* tags. It is carefully curated from all kinds of OSM relations and ways. The zones mentioned in this issue were added to obtain their data from the OSM boundaries of the jurisdictions that changed their timekeeping methods as of the 2016d tzdb release (which was the very first timezone-boundary-builder release).

from timeshape.

Indeed, after checking https://data.iana.org/time-zones/tzdb/NEWS for 2016b release, it seems the new zone id Asia/Barnaul was introduced to cover Altai Krai and Altai Republic. Please be aware both Asia/Barnaul and Asia/Krasnoyarsk are both +7 now (after the 2016 DST switch).
P.S. @evansiroky I didn't actually realize the depth of changes you have to make to OSM data! If I may ask, have you considered reporting the wrong results back to OSM? I'm not sure which path is easier, special-casing or fixing the data at the source. If you tried reporting that to OSM, I'd be very curious to know about your experience.

from timeshape.

@RomanIakovlev, one doesn't simply report errors to OSM and expect them to be fixed. Also, the method in which timezones are created in OSM is somewhat controversial because the OSM wiki page about the timezone relation notes that this is not a generally accepted thing to map as a standalone boundary which would make it difficult for a number of timezones.

Despite that wiki page, OSM mappers still map these relations and timezone-boundary-builder does pull in some of these relations directly. The last time I inspected the quality of the OSM timezone data as a whole, I deemed it insufficient to use in a release as a whole, but I do believe it is getting better. Eventually, I want to improve the timezone-boundary-builder script so that it will compare the data in timezone-boundary-builder with the timezone relations in OSM, but I have some other priorities I need to get to first.

Due to the unofficial status of the timezone relation in OSM, the current incompleteness of data and the convenience of having a stable shapefile to download for each tzdb release, I do believe there's still a need for timezone-boundary-builder to assemble things together in a piecemeal fashion.

from timeshape.

Thanks @evansiroky for this info, it's very insightful, especially about the somewhat unofficial status of the standalone timezone relation in OSM. I guess there's a significant number of timezones not matching a single administrative boundary (or even a partition of multiple boundaries) – at least the oceans.

Just thinking out loud here: it seems the hybrid approach would work the best in this case – some relations are tagged with both timezone and administrative (where a one-to-one mapping exist, e.g. most if not all the European countries), while the others are tagged with just the timezone (where multiple high-level administrative relations belong to same timezone, e.g. the Asia/Krasnoyarsk or some other big Siberian timezones).

from timeshape.

The hybrid approach you are describing already exists in OSM. I've created evansiroky/timezone-boundary-builder#91 so doing a full analysis of OSM timezone relations is on the radar.

from timeshape.