The geo lookup would be expensive computationally, and also there are arguments over geographic boundaries that could make TZ lookup ambiguous (the author gave an example in the article)
The geo lookup would be expensive computationally, and also there are arguments over geographic boundaries that could make TZ lookup ambiguous (the author gave an example in the article)
> The geo lookup would be expensive computationally
Not really? There's not that many timezones, globally, and I think their polygon data is in OSM / could be obtained from OSM. Simply brute-force colliding a single point with all of them I would expect to be basically "instantaneous", but there are a number of trivial optimizations, like bounding boxes, that you could do to speed it up.
(Point-in-polygon is not terribly expensive; it's O(segments) in your polygon.)
That said, there are problems with that, as you mention. I just don't think "computationally expensive" is one of them.
Oddly enough I built an API a few years ago that does exactly that, using timezone polygons derived from OpenStreetMap: https://timezones.datasette.io/timezones/by_point?longitude=...