4 ms·

>That said, you should really use UTC. No, that "store UTC everywhere" is often repeated but it's incorrect advice when applied to future human-constructed dat

by jasode 3y ago

>That said, you should really use UTC. No, that "store UTC everywhere" is often repeated but it's incorrect advice when applied to future human-constructed datetimes such as appointments or social events. Future "human-interpreted wall-clock" datetimes cannot be unambiguously stored as future UTC values with perfect roundtrip fidelity. I've tried to explain the difference in previous comment: https://news.ycombinator.com/item?id=19534843 https://news.ycombinator.com/item?id=19534843

Glyptodon 3y ago
The number of times very smart people seem to think having to alter a pile of UTC times because their associated region has changed their DST behavior is better than having local zoneless and just changing TZDB always weirds me out.
graemep 3y ago
That is a good point, but fortunately a rare case. The other problem is that when you are using human inputs such as appointments you may not know which is appropriate. If I arrange a meeting with someone in another timezone, and there is such a change, how can a system know whether I want the UTC time, my timezone, or the other person's timezone. I am not sure there is a good way to do this in many cases. As you say some culturally defined times are definitely tied to the local timezone, but a lot of things will not be. There is a loss of information, but that information may not be useful on many cases. I think I agree with you in that there is no universal solution. However, store UTC is probably good enough a lot of the time. In general, timezone changes would be announced well ahead of time so UTC would be fine except for times fixed far ahead. I have actually lived through timezone changes that were decided on in emergency circumstances (Sri Lanka faced with a severe electricity shortage) and the result was chaos. People genuinely did not know whether an appointment would take place in "old time" or "new time"! No system devised earlier could have coped with that because intent was no unambiguous.
- Hackbraten 3y ago
  > how can a system know whether I want the UTC time, my timezone, or the other person's timezone A decent system will allow the user to make that choice on a case-by-case basis but assume the common case as a default. I've seen apps pull that off successfully, e.g. iCal.

by jasode 3y ago

Glyptodon 3y ago

The number of times very smart people seem to think having to alter a pile of UTC times because their associated region has changed their DST behavior is better than having local zoneless and just changing TZDB always weirds me out.

graemep 3y ago

That is a good point, but fortunately a rare case. The other problem is that when you are using human inputs such as appointments you may not know which is appropriate. If I arrange a meeting with someone in another timezone, and there is such a change, how can a system know whether I want the UTC time, my timezone, or the other person's timezone. I am not sure there is a good way to do this in many cases. As you say some culturally defined times are definitely tied to the local timezone, but a lot of things will not be. There is a loss of information, but that information may not be useful on many cases. I think I agree with you in that there is no universal solution. However, store UTC is probably good enough a lot of the time. In general, timezone changes would be announced well ahead of time so UTC would be fine except for times fixed far ahead. I have actually lived through timezone changes that were decided on in emergency circumstances (Sri Lanka faced with a severe electricity shortage) and the result was chaos. People genuinely did not know whether an appointment would take place in "old time" or "new time"! No system devised earlier could have coped with that because intent was no unambiguous.

Hackbraten 3y ago
> how can a system know whether I want the UTC time, my timezone, or the other person's timezone A decent system will allow the user to make that choice on a case-by-case basis but assume the common case as a default. I've seen apps pull that off successfully, e.g. iCal.