6 ms·

Calendar apps expose all of the weird edge cases in dates and times. For a specific instance of a specific event that never needs to move, TAI will work. Howeve

Calendar apps expose all of the weird edge cases in dates and times. For a specific instance of a specific event that never needs to move, TAI will work. However, suppose that you schedule a meeting for 28 March at 13:00. You then move that meeting forward a week, crossing a DST switch. If you simply add 604800 seconds to the TAI, that meeting will be at 14:00, which is surprising. OK, easy enough to solve; convert the TAI back to the local timezone, add 7 to the day field (carrying into month and year, as needed), and you're good to go. Now suppose that the meeting was set up in the US, and you realized that you needed to reschedule the meeting while you were travelling in Germany. You get back to the US, and suddenly the meeting is an hour early, because DST rules aren't universal. Worse, imagine a recurring meeting, every week at noon. You've got the TAI for the original instance, but as you cross a DST boundary, some places will shift according to DST and others won't, and thus you have half the attendees showing up at the wrong time. Finally, TAI introduces the leap second bug for calendars. When you schedule a meeting for noon next year, you want that to happen at noon, not now plus however many seconds. If a leap second is introduced, you don't want that meeting to happen at one second before or after noon. TBH, if you find yourself in a situation where you need to deal with calendar events, I recommend updating your CV.

fc417fc802 1y ago
I'll preface this by stating that I fully realize that localized datetime is absolutely byzantine and fraught with difficulties. That's the rationale for leaving it to an external library as close to 100% of the time as possible. I also realize that there might well be complexities involved in calendar software that I'm unaware of. Hence my comment - I'm genuinely interested to learn. That said, I think your examples are all fairly clear examples of errors in reasoning by the programmer. Specifically they stem from conceptual mistakes regarding the relation of different logic domains (by which I'm referring to storage, display, scheduling, etc). You never move events around in TAI (the unambiguous storage format) just as you don't go manually flipping bits in an SQLite database. You always work in a localized time because that's what the user is reasoning in. And you use the datetime library to implement as much of those manipulations as possible. > US vs Germany, conflicting DST rules. Go back to the era before smartphones and PDAs and the internet. You're in Germany on a business trip. You call your secretary to reschedule next weeks meeting back home. You don't use German time when doing that, you use US time. Events have a location which has a timezone. Scheduling happens in that timezone. Blindly using the current local timezone of the device is a reasoning error. Storage, scheduling, and presentation are distinct logic domains. > you have half the attendees showing up at the wrong time. There is a single unique TAI time for a given event (after all that's the entire point of using UTC or TAI or what have you). All attendees will see an equivalent local time barring a bug in the datetime library. See my earlier point regarding which timezone to use for the computation. > TAI introduces the leap second bug for calendars. Only if you make the mistake of attempting to manually manipulate your data storage format. The point of TAI as opposed to UTC in this specific case is to offload the complexity of handling leap seconds onto the datetime library so that you don't need to worry about it.
- et1337 1y ago
  The problem is TAI is not the source of truth in real life. In real life, Arizona can change its laws and suddenly that event is going to happen at a different TAI timestamp. That’s why the unambiguous storage format has to be a date time with time zone, and not just a timestamp.
  - fc417fc802 1y ago
    Good point. Seems I also made a reasoning error by failing to consider that timezones, being arbitrary legal constructs, can be changed at the drop of a hat. However it doesn't seem particularly difficult to fix. My error was suggesting using TAI for storage. I guess that works only for events in the past. So the timezone that the event belongs to is what should have been used for storage, you should forget leap seconds exist because this is a human centric calendar so who cares, and you should trust the datetime library to just do the right thing when converting timestamps. Is there some other issue I'm missing? Because so long as all the timezone complexity is stuffed into the datetime library (and thus NotMyProblem™) it seems like the really difficult part is already solved for you.
    - funcDropShadow 1y ago
      In practice it is difficult enough, to do the right date arithmetic using the datetime library in the right timezone.
- ElectricalUnion 1y ago
  > You never move events around in TAI (the unambiguous storage format) just as you don't go manually flipping bits in an SQLite database. You actually do. From the point of view of future scheduled events, a event scheduled for 13h00 in a specific timezone is still "13h00 in a specific timezone" even when crazy people on that timezone suddenly declare a new Daylight savings time to start before the event happens. All future "timestamps" are prone to move due to such shenanigans. And you need to keep your timezone DB as updated as possible to update thing as soon as possible, if you don't want users with wrong times on their future events. If you're not doing something like full rfc9557 https://datatracker.ietf.org/doc/html/rfc9557 https://datatracker.ietf.org/doc/html/rfc9557 "Internet Extended Date/Time Format (IXDTF)" [iso 8601 local time + as-of-now known timezone offset + IANA timezone] as "timestamps" you're probably truncating important information that will bite you back later if you're doing a calendar/scheduler.

fc417fc802 1y ago

I'll preface this by stating that I fully realize that localized datetime is absolutely byzantine and fraught with difficulties. That's the rationale for leaving it to an external library as close to 100% of the time as possible. I also realize that there might well be complexities involved in calendar software that I'm unaware of. Hence my comment - I'm genuinely interested to learn. That said, I think your examples are all fairly clear examples of errors in reasoning by the programmer. Specifically they stem from conceptual mistakes regarding the relation of different logic domains (by which I'm referring to storage, display, scheduling, etc). You never move events around in TAI (the unambiguous storage format) just as you don't go manually flipping bits in an SQLite database. You always work in a localized time because that's what the user is reasoning in. And you use the datetime library to implement as much of those manipulations as possible. > US vs Germany, conflicting DST rules. Go back to the era before smartphones and PDAs and the internet. You're in Germany on a business trip. You call your secretary to reschedule next weeks meeting back home. You don't use German time when doing that, you use US time. Events have a location which has a timezone. Scheduling happens in that timezone. Blindly using the current local timezone of the device is a reasoning error. Storage, scheduling, and presentation are distinct logic domains. > you have half the attendees showing up at the wrong time. There is a single unique TAI time for a given event (after all that's the entire point of using UTC or TAI or what have you). All attendees will see an equivalent local time barring a bug in the datetime library. See my earlier point regarding which timezone to use for the computation. > TAI introduces the leap second bug for calendars. Only if you make the mistake of attempting to manually manipulate your data storage format. The point of TAI as opposed to UTC in this specific case is to offload the complexity of handling leap seconds onto the datetime library so that you don't need to worry about it.

et1337 1y ago
The problem is TAI is not the source of truth in real life. In real life, Arizona can change its laws and suddenly that event is going to happen at a different TAI timestamp. That’s why the unambiguous storage format has to be a date time with time zone, and not just a timestamp.
- fc417fc802 1y ago
  Good point. Seems I also made a reasoning error by failing to consider that timezones, being arbitrary legal constructs, can be changed at the drop of a hat. However it doesn't seem particularly difficult to fix. My error was suggesting using TAI for storage. I guess that works only for events in the past. So the timezone that the event belongs to is what should have been used for storage, you should forget leap seconds exist because this is a human centric calendar so who cares, and you should trust the datetime library to just do the right thing when converting timestamps. Is there some other issue I'm missing? Because so long as all the timezone complexity is stuffed into the datetime library (and thus NotMyProblem™) it seems like the really difficult part is already solved for you.
  - funcDropShadow 1y ago
    In practice it is difficult enough, to do the right date arithmetic using the datetime library in the right timezone.
ElectricalUnion 1y ago
> You never move events around in TAI (the unambiguous storage format) just as you don't go manually flipping bits in an SQLite database. You actually do. From the point of view of future scheduled events, a event scheduled for 13h00 in a specific timezone is still "13h00 in a specific timezone" even when crazy people on that timezone suddenly declare a new Daylight savings time to start before the event happens. All future "timestamps" are prone to move due to such shenanigans. And you need to keep your timezone DB as updated as possible to update thing as soon as possible, if you don't want users with wrong times on their future events. If you're not doing something like full rfc9557 https://datatracker.ietf.org/doc/html/rfc9557 https://datatracker.ietf.org/doc/html/rfc9557 "Internet Extended Date/Time Format (IXDTF)" [iso 8601 local time + as-of-now known timezone offset + IANA timezone] as "timestamps" you're probably truncating important information that will bite you back later if you're doing a calendar/scheduler.