3 ms·

My point is that those are rare. By far the most common mistake is to store a timestamp that should have a zone without one. If we're agreed on that, and are n

My point is that those are rare. By far the most common mistake is to store a timestamp that should have a zone without one. If we're agreed on that, and are not trying to use the fact that time conventions can change as an excuse for writing nominal datetimes everywhere then great. I'm really not interested in an argument.

fauigerzigerk 1y ago
>My point is that those are rare I disagree. Storing appointment reminders is not rare. Storing the datetime of future social events or deadlines is not rare. I'm not interested in an argument either. Just use the correct representation for the use case at hand. It doesn't matter how rare or not rare it is in your work.
- omnicognate 1y ago
  Are you arguing in favour of storing a nominal datetime without additional information that allows it to be resolved to an instant in time in those cases, or are you just debating the nature of that extra information? If the latter, we don't disagree. There's more than one way to do it and plenty of use cases with special requirements (though IANA timezones are sufficient for most purposes). If the former, we profoundly disagree and if you are a professional programmer working in a field that makes significant use of times across multiple regions you will create misery for your colleagues until you change your approach. But you will at least be far from alone in doing so...
- burntsushi 1y ago
  What's rare is a physical location changing its IANA time zone identifier. It is absolutely a fact that for the use cases you describe, you do eventually have to turn it into an instant in time. Otherwise you don't know when to issue appointment reminders and so on. Because a location changing its IANA time zone identifier is rare, then capturing the "nominal" datetime, plus the offset and the time zone identifier is usually sufficient. That information can be encoded using RFC 9557. The offset can be used as a checksum of sorts to avoid silent bugs in cases where the location changes its DST rules. It does not help with your Ukraine example. However, the only way to make your Ukraine example work is to necessarily have a way of mapping a physical location to an IANA time zone identifier. The IANA tzdb does not provide that on its own. This may be a fair bit of additional work that is not worth doing. It's definitely wrong to just store an instant in time with a time zone though. You want the local datetime, the offset and the time zone at minimum. I'm surprised nobody in this thread has brought up RFC 9557.
  - akio 1y ago
    Evan Siroky's Timezone Boundary Builder[0] is a good source of time zone boundary mappings. It can be used via a library in nearly any language you would want[1], or loaded directly into Postgres and used with PostGIS in queries[2] (of course, if you load it into your DB you should have a process for keeping it updated). It would be wonderful if Jiff supported coordinates-to-tz lookups out of the box :) [0]: https://github.com/evansiroky/timezone-boundary-builder/releases https://github.com/evansiroky/timezone-boundary-builder/rele... [1]: https://github.com/evansiroky/timezone-boundary-builder#lookup-libraries https://github.com/evansiroky/timezone-boundary-builder#look... [2]: https://www.crunchydata.com/blog/timezone-transformation-using-location-data-and-postgis https://www.crunchydata.com/blog/timezone-transformation-usi...
    - burntsushi 1y ago
      I'm aware, yet it doesn't invalidate my point. You'll note that I didn't say it was impossible to do. You would also need to rely on this database being updated similar to the tzdb, which is another data dependency to consider. There is also the problem that there isn't an established interchange format for such things, but there is one for IANA time zone identifiers (RFC 9557). Finally, the database you linked doesn't appear to track historical data, unlike the tzdb. So if Ukraine reacquired territory, you'd end up with a wrong answer if looking at appointments scheduled in the past.
      - akio 1y ago
        Past events should just be stored as instants, not as a local time plus location or time zone. Further, I believe the historical data is meant to be handled by the named time zone, so Russia moving Dnipro to MSK would create a new time zone, call it Europe/Dnipro, then Ukraine reacquiring the territory and moving it back to EET would keep (or further split) Europe/Dnipro, and the historical changes of Dnipro would be handled by tzdb. So even if you did store past events with a local time plus a location (which you should not do), I don't think Ukraine reacquiring the territory would cause problems, although we're really stretching my knowledge of IANA named zones and I could certainly be wrong.

fauigerzigerk 1y ago

>My point is that those are rare I disagree. Storing appointment reminders is not rare. Storing the datetime of future social events or deadlines is not rare. I'm not interested in an argument either. Just use the correct representation for the use case at hand. It doesn't matter how rare or not rare it is in your work.

omnicognate 1y ago
Are you arguing in favour of storing a nominal datetime without additional information that allows it to be resolved to an instant in time in those cases, or are you just debating the nature of that extra information? If the latter, we don't disagree. There's more than one way to do it and plenty of use cases with special requirements (though IANA timezones are sufficient for most purposes). If the former, we profoundly disagree and if you are a professional programmer working in a field that makes significant use of times across multiple regions you will create misery for your colleagues until you change your approach. But you will at least be far from alone in doing so...
burntsushi 1y ago
What's rare is a physical location changing its IANA time zone identifier. It is absolutely a fact that for the use cases you describe, you do eventually have to turn it into an instant in time. Otherwise you don't know when to issue appointment reminders and so on. Because a location changing its IANA time zone identifier is rare, then capturing the "nominal" datetime, plus the offset and the time zone identifier is usually sufficient. That information can be encoded using RFC 9557. The offset can be used as a checksum of sorts to avoid silent bugs in cases where the location changes its DST rules. It does not help with your Ukraine example. However, the only way to make your Ukraine example work is to necessarily have a way of mapping a physical location to an IANA time zone identifier. The IANA tzdb does not provide that on its own. This may be a fair bit of additional work that is not worth doing. It's definitely wrong to just store an instant in time with a time zone though. You want the local datetime, the offset and the time zone at minimum. I'm surprised nobody in this thread has brought up RFC 9557.
- akio 1y ago
  Evan Siroky's Timezone Boundary Builder[0] is a good source of time zone boundary mappings. It can be used via a library in nearly any language you would want[1], or loaded directly into Postgres and used with PostGIS in queries[2] (of course, if you load it into your DB you should have a process for keeping it updated). It would be wonderful if Jiff supported coordinates-to-tz lookups out of the box :) [0]: https://github.com/evansiroky/timezone-boundary-builder/releases https://github.com/evansiroky/timezone-boundary-builder/rele... [1]: https://github.com/evansiroky/timezone-boundary-builder#lookup-libraries https://github.com/evansiroky/timezone-boundary-builder#look... [2]: https://www.crunchydata.com/blog/timezone-transformation-using-location-data-and-postgis https://www.crunchydata.com/blog/timezone-transformation-usi...
  - burntsushi 1y ago
    I'm aware, yet it doesn't invalidate my point. You'll note that I didn't say it was impossible to do. You would also need to rely on this database being updated similar to the tzdb, which is another data dependency to consider. There is also the problem that there isn't an established interchange format for such things, but there is one for IANA time zone identifiers (RFC 9557). Finally, the database you linked doesn't appear to track historical data, unlike the tzdb. So if Ukraine reacquired territory, you'd end up with a wrong answer if looking at appointments scheduled in the past.
    - akio 1y ago
      Past events should just be stored as instants, not as a local time plus location or time zone. Further, I believe the historical data is meant to be handled by the named time zone, so Russia moving Dnipro to MSK would create a new time zone, call it Europe/Dnipro, then Ukraine reacquiring the territory and moving it back to EET would keep (or further split) Europe/Dnipro, and the historical changes of Dnipro would be handled by tzdb. So even if you did store past events with a local time plus a location (which you should not do), I don't think Ukraine reacquiring the territory would cause problems, although we're really stretching my knowledge of IANA named zones and I could certainly be wrong.