3 ms·

While UTC timestamps look like they solve all of the problems in one passing, they have plenty of edge cases that can blow up spectacularly. A good example of t

While UTC timestamps look like they solve all of the problems in one passing, they have plenty of edge cases that can blow up spectacularly. A good example of this is daylight saving time and countries changing their rules around it. You would think this is a rare occurrence, but it actually happens pretty often [0]! In the last ten years, fourteen countries have abolished daylight saving time. [0] https://en.wikipedia.org/wiki/Daylight_saving_time_by_country#Past_observance https://en.wikipedia.org/wiki/Daylight_saving_time_by_countr...

RandomThoughts3 2y ago
Technically you could use TAI for most things internally and use an offset when you display. It works perfectly for records. The only issue is with scheduled things when your users probably want to point at something in their timezone.
- labster 2y ago
  The main problem is that future values of TAI converted into most time zones is nondeterministic. On the other hand, at least you can guarantee all TAI seconds will actually occur.
- ikekkdcjkfke 2y ago
  Or toLocalDisplayString(TAI timestamp). It seems like timezones and their rules change over time and geographic location, using todays rules to show dates back in time with previous rules would be broken right?
  - jitl 2y ago
    Well, any correct time handling library will use something like the IANA timezone database (aka tz/tzdb/zoneinfo) which stores all the changes in timezone rules for localities over the years - a library that only knows "today's rules" would be fundamentally broken as you say. So the internals of toLocalDisplayString(timestamp, timezone, calendar, locale) should look up the appropriate rules in effect at the timestamp and use those to decide the local time to display.
dunham 2y ago
We hit this with the US timezone change in 2005. The front-end devs were using moment.js which didn't know about the previous start/end dates. These days I try to encode everything that is logically a date as yyyy-mm-dd. And if I need to do math with it, I often work with an offset julian date as an integer. But that only works if you stay on this side of September 1752: % cal 09 1752 September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
- layer8 2y ago
  Before roughly 100 years ago, calendar dates were region-dependent anyway (Russia was still on the Julian calendar until 1918), and time zones didn’t really exist until roughly 150 years ago (their establishment mostly being motivated by the spreading of railways). It’s okay to apply the perpetual Gregorian calendar both into the past and the future by default. It probably won’t last more than a couple thousand years into the future as well, considering Earth’s decelerating rotation.
  - nradov 2y ago
    Some Orthodox Churches still use the Julian calendar even today. Of course they aren't major software customers.
  - langcss 2y ago
    I think time zones not existing really meant there were infinite time zones, because you use the sun to tell the time.
    - layer8 2y ago
      The solar day varies in length by more than a minute over the year. That doesn't correspond to a well-defined time zone. Also, "zone" implies a geographical area, which meridians arguably aren't.
- LoganDark 2y ago
  oof, there went 12 days. at least this isn't a regular occurrence outside of 1752 (unless you have DID, I guess)
naasking 2y ago
Sure, but now you've reduced the scope of the problem to a few edge cases. Every other solution I've seen still has these edge cases and doesn't solve the core problem as simply as UTC. If you think otherwise, can you describe or provide a link to these other solutions?
- lxgr 2y ago
  For region-specific events (which includes most physical meetings, by convention many financial processes etc.), it's much safer to store both the local time and time zone city, as well as the UTC offset at the time of writing, and to convert to UTC only at runtime using an up-to-date time zone database. That way, you can identify all of: - Future timestamps you might want to re-process, e.g. for notification scheduling, because the future UTC conversion has changed between scheduling/updating the event and now. - Equivalently, timestamps written by software/an OS running an outdated TZ database. You should talk to them; things are about to go wrong if the date is in the non-too-far future! - Trivially and without conversion, the local time that people will use in the meeting notes, documenting that you missed the meeting because you didn't update your TZ database and dialed in to the meeting an hour late
mmis1000 2y ago
Like, what if you only need the date but not the time? You can use timestamp to store a birthday, but which in which timezone should you transform it back to date? Or what if it is specifically about time in timezone independent way? You want to wake up ate 06:00 no matter in any timezone. Just something like alert. You could use part of ISO8601 like 2020-02-02 or 06:00:00 to store exactly what you specify. But with timestamp, not so much.
9dev 2y ago
I’ve been thinking about this; does a timestamp even work, then, without not only a time zone, but a location? I mean time zones are poor man’s locations, but if we want to do this properly…

RandomThoughts3 2y ago

Technically you could use TAI for most things internally and use an offset when you display. It works perfectly for records. The only issue is with scheduled things when your users probably want to point at something in their timezone.

labster 2y ago
The main problem is that future values of TAI converted into most time zones is nondeterministic. On the other hand, at least you can guarantee all TAI seconds will actually occur.
ikekkdcjkfke 2y ago
Or toLocalDisplayString(TAI timestamp). It seems like timezones and their rules change over time and geographic location, using todays rules to show dates back in time with previous rules would be broken right?
- jitl 2y ago
  Well, any correct time handling library will use something like the IANA timezone database (aka tz/tzdb/zoneinfo) which stores all the changes in timezone rules for localities over the years - a library that only knows "today's rules" would be fundamentally broken as you say. So the internals of toLocalDisplayString(timestamp, timezone, calendar, locale) should look up the appropriate rules in effect at the timestamp and use those to decide the local time to display.

dunham 2y ago

We hit this with the US timezone change in 2005. The front-end devs were using moment.js which didn't know about the previous start/end dates. These days I try to encode everything that is logically a date as yyyy-mm-dd. And if I need to do math with it, I often work with an offset julian date as an integer. But that only works if you stay on this side of September 1752: % cal 09 1752 September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

layer8 2y ago
Before roughly 100 years ago, calendar dates were region-dependent anyway (Russia was still on the Julian calendar until 1918), and time zones didn’t really exist until roughly 150 years ago (their establishment mostly being motivated by the spreading of railways). It’s okay to apply the perpetual Gregorian calendar both into the past and the future by default. It probably won’t last more than a couple thousand years into the future as well, considering Earth’s decelerating rotation.
- nradov 2y ago
  Some Orthodox Churches still use the Julian calendar even today. Of course they aren't major software customers.
- langcss 2y ago
  I think time zones not existing really meant there were infinite time zones, because you use the sun to tell the time.
  - layer8 2y ago
    The solar day varies in length by more than a minute over the year. That doesn't correspond to a well-defined time zone. Also, "zone" implies a geographical area, which meridians arguably aren't.
LoganDark 2y ago
oof, there went 12 days. at least this isn't a regular occurrence outside of 1752 (unless you have DID, I guess)

naasking 2y ago

Sure, but now you've reduced the scope of the problem to a few edge cases. Every other solution I've seen still has these edge cases and doesn't solve the core problem as simply as UTC. If you think otherwise, can you describe or provide a link to these other solutions?

lxgr 2y ago
For region-specific events (which includes most physical meetings, by convention many financial processes etc.), it's much safer to store both the local time and time zone city, as well as the UTC offset at the time of writing, and to convert to UTC only at runtime using an up-to-date time zone database. That way, you can identify all of: - Future timestamps you might want to re-process, e.g. for notification scheduling, because the future UTC conversion has changed between scheduling/updating the event and now. - Equivalently, timestamps written by software/an OS running an outdated TZ database. You should talk to them; things are about to go wrong if the date is in the non-too-far future! - Trivially and without conversion, the local time that people will use in the meeting notes, documenting that you missed the meeting because you didn't update your TZ database and dialed in to the meeting an hour late

mmis1000 2y ago

Like, what if you only need the date but not the time? You can use timestamp to store a birthday, but which in which timezone should you transform it back to date? Or what if it is specifically about time in timezone independent way? You want to wake up ate 06:00 no matter in any timezone. Just something like alert. You could use part of ISO8601 like 2020-02-02 or 06:00:00 to store exactly what you specify. But with timestamp, not so much.

9dev 2y ago

I’ve been thinking about this; does a timestamp even work, then, without not only a time zone, but a location? I mean time zones are poor man’s locations, but if we want to do this properly…