How to decide when timezones overlap

[CopyOfA]

I'm working with all of the polygons assembled by the timezonefinder team, and I've found some instances where timezones appear to overlap. For example, Asia/Thimphu and Asia/Shanghai have two polygons that are shared between the two timezone polygons: one on the western side of Bhutan and one in north-north-east Bhutan. (Another area shared by two timezone polygons is between Asia/Shanghai and Asia/Urumqi, where basically the entirety of Asia/Urumqi is within Asia/Shanghai.) When I query timezonefinder for the timezone on a point that is within one of these shared polygons (e.g., lng=90.946322933095, lat=27.956793099786655), the returned timezone is Asia/Thimphu. How is the conflict between these two timezone boundaries being resolved?

[cookesan]

The overlap is not resolved as “both” or by a timezone rule. The docs explicitly note that the upstream boundary data can contain overlapping polygons and that timezonefinder does not support returning multiple matches; it returns one match.

In the current implementation, the result comes from the precomputed H3 shortcut plus the ordered candidate polygon list. timezone_at() checks candidate polygons and returns the first matching zone it reaches, with a shortcut fast path for cells that are precomputed as unique. So Asia/Thimphu for that coordinate is an artifact of the packaged data/order/index, not a statement that the other overlapping polygon is invalid.

If you need to reason about overlaps, use the geometry data directly and collect all polygons containing the point. unique_timezone_at() can help detect shortcut cells that are unambiguous, but it will not list all overlapping zones.

[jannikmi]

Thanks @CopyOfA for bringing this up.
Thank you @cookesan for your quick and helpful answer!

I want add to that:

• It would be possible to build timezone lookup functionality able to handle timezone boundary ambiguities (multiple matches for one coordinate pair). Feel free to raise an Issue describing what exactly you need or open a PR with respective code changes.
• You can understand the behavior visually with the GUI:
  https://timezonefinder.michelfe.it/gui/0_90.946322933095_27.956793099786655
  I have to note though that the timezonefinder version and thereby also the timezone boundary data is not up to date (cf. Update the timezonefinder version used in the GUI timezonefinder_gui#1)
• the underlying boundary data comes from https://github.com/evansiroky/timezone-boundary-builder
• another GUI from an alternative libary: https://ringsaturn.github.io/tzf-web/?markers=%5B%7B%22lat%22%3A35.7354%2C%22lng%22%3A-110.1242%7D%2C%7B%22lat%22%3A36.058%2C%22lng%22%3A-111.1871%7D%5D&lat=36.057981&lng=-110.643311&zoom=9

[ringsaturn]

You may need choose your own preferences for use caces. Asia/Urumqi works fine with normal life but need to use Asia/Shanghai for public services like airport/train to keep data consistence.

https://ringsaturn.github.io/tzf-web/?markers=%5B%7B%22lat%22%3A43.5804%2C%22lng%22%3A86.6602%7D%5D&lat=41.112469&lng=94.086914&zoom=5

And for the "Asia/Thimphu and Asia/Shanghai" case, the background is Bhutan–China border.

---

To be honest, it's not easy to make "best" choice in the timezone look up libraries for the overlap timezones, since potential political reasons also exist.