5 ms·

So I’ve been wondering this for a while. Why don’t we actually use a „spacetime“ format, like 2024-12-05T23:03:47+48.86,2.34 instead of bothering with time zone

by 9dev 2y ago

So I’ve been wondering this for a while. Why don’t we actually use a „spacetime“ format, like 2024-12-05T23:03:47+48.86,2.34 instead of bothering with time zones at all? Why not use arbitrary precision coordinates in their place? That would solve a bunch of issues with time zones at once, like not needing to know which time offset existed at the point in time in question. Depending on the use case, we could make the coordinates more precise, but regularly, I’d wager one or two digits would suffice for current timestamp usage.

iforgotpassword 2y ago
But then you'd still need to figure out in what timezone those coordinates are to know when it is/was, so you made the problem even more complex. Unless you're suggesting we get rid of timezones in general, in which case it would be the same time everywhere and we don't need anything for disambiguation, i.e. we can get rid of the coordinates. Inb4 that other blog post that explains why getting rid of timezones is troublesome in everyday life.
- wongarsu 2y ago
  It's more complex, but usually it better matches user intent. If I say the conference starts on 2027-04-05 13:09 in Berlin, and Germany decides to change their time zones or daylight saving time rules sometime in 2025, your stored offset or stored UTC time is now wrong. The conference will start whenever local clocks show 13:09, and you have no reliable way of knowing which time zone local clocks will be in in two years time. Of course if we go down that path we should also add a format to indicate offsets. If I say I'll be back in 10 minutes, that interval shouldn't change no matter what happens to the time zone. To perfectly disambiguate it you would need to store it as current time (with timezone or UTC) plus the intended offset. This would also "solve" a lot of issues around leap seconds and the inability to predict them more than six months into the future.
efitz 2y ago
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)
- deathanatos 2y ago
  > 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.
  - simonw 2y ago
    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=-116.23&latitude=43.61 https://timezones.datasette.io/timezones/by_point?longitude=...
canucker2016 2y ago
There's usually a need for a human to see/understand the timezone information - probably doesn't matter how you store it, but showing JUST the RAW spacetime format will annoy a certain group of users (the 99% who don't/can't map from lat/long or whatever format you choose to a more human-legible "hometown, country" format)

by 9dev 2y ago

iforgotpassword 2y ago

But then you'd still need to figure out in what timezone those coordinates are to know when it is/was, so you made the problem even more complex. Unless you're suggesting we get rid of timezones in general, in which case it would be the same time everywhere and we don't need anything for disambiguation, i.e. we can get rid of the coordinates. Inb4 that other blog post that explains why getting rid of timezones is troublesome in everyday life.

wongarsu 2y ago
It's more complex, but usually it better matches user intent. If I say the conference starts on 2027-04-05 13:09 in Berlin, and Germany decides to change their time zones or daylight saving time rules sometime in 2025, your stored offset or stored UTC time is now wrong. The conference will start whenever local clocks show 13:09, and you have no reliable way of knowing which time zone local clocks will be in in two years time. Of course if we go down that path we should also add a format to indicate offsets. If I say I'll be back in 10 minutes, that interval shouldn't change no matter what happens to the time zone. To perfectly disambiguate it you would need to store it as current time (with timezone or UTC) plus the intended offset. This would also "solve" a lot of issues around leap seconds and the inability to predict them more than six months into the future.

efitz 2y ago

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)

deathanatos 2y ago
> 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.
- simonw 2y ago
  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=-116.23&latitude=43.61 https://timezones.datasette.io/timezones/by_point?longitude=...

canucker2016 2y ago

There's usually a need for a human to see/understand the timezone information - probably doesn't matter how you store it, but showing JUST the RAW spacetime format will annoy a certain group of users (the 99% who don't/can't map from lat/long or whatever format you choose to a more human-legible "hometown, country" format)