[fc417fc802]

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.

[ElectricalUnion]

> 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 "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]

It's a good point. I responded to the adjacent comment.

After glancing at that RFC I'm unclear about the purpose of the UTC offset. Is it simply an error check to catch the case of a datetime library with outdated timezone information? Otherwise it seems like the library will have all the historical information on hand so it shouldn't have any use for it.

[et1337]

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]

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]

In practice it is difficult enough, to do the right date arithmetic using the datetime library in the right timezone.

[toast0]

IMHO, based on zero evidence, for scheduling, very few people are scheduling events beyond a minute of precision. TAI is a better timescale than UTC, but UTC is better supported and leap seconds might be going away, so pretending they don't exist is probably a better choice.

But timezones are super byzantine. Especially when the rules update. More especially when the rules update on short notice.

If you scheduled an event at 5 pm local time at some place on some day and the rules change, the event's UTC (and TAI) would change. But you may want to confirm with the user, because maybe they're calling into an event somewhere else and they entered their local time but the event is really scheduled in the other time.

You might also have fun when multiple clients are using the same event and the clients and the server don't all agree on timezone definitions. iCalendar suggests that the timezone definition be included in the files, but my experience is definitions are often missing and most things ignore the definitions if present; you've got to include a timezone name the software is going to process as you want or you won't have a good time (or use UTC and hope)

If the event was scheduled in the DST window, the time may no longer exist, or may be ambiguous. iCalendar has rules for that, but they might not actually meet your user's needs (otoh, who is scheduleding things at 2-3am on a Sunday ... probably not a lot of people)

[fc417fc802]

> the clients and the server don't all agree on timezone definitions

Isn't that scenario unsalvageable regardless? It presumably means one or more of the devices are displaying the wrong time to the user. Or at least will be upon arrival in the timezone of the event.

For example (intentionally extreme) suppose the library used by my calendar thinks EST is -4, the OS on my device thinks EST is -6, and everyone else thinks EST is -5. What possible program logic could prevent disaster in this scenario?

It's a really interesting edge case to point out, I'm just not clear what a sensible algorithm for handling it would look like. I strongly suspect that assuming that can never happen is the right answer. Everyone agrees the event is scheduled for 9 am EST. If outdated client software translates that to PST incorrectly or displays the incorrect time on the clock then the affected user is going to have issues and I don't see what the programmer can realistically do about it.

> ... DST window, the time may no longer exist, or may be ambiguous.

Assuming the timestamp disambiguates the daylight timezone from the standard timezone this should be handled gracefully by the datetime library since the stale timestamp is merely "out of bounds" for that timezone now that the laws changed. I'm failing to think of a scenario where it becomes ambiguous (although reasoning through this is once again reinforcing my view that we should have ditched DST long ago).

However this did cause me to realize that there's an additional edge case for far future events where the timezone is modified multiple times. If the event timestamp was never updated in the interim you land in an ambiguous situation and have no way to detect it.

I'm not sure that particular edge case is worth worrying about, but it seems like tracking a second timestamp indicating the last time that the event was processed by the datetime library would resolve it. The library should hopefully have all the necessary historical information on hand to update a long since stale timestamp (I haven't tested this though). Anyway if it doesn't I don't see that there's anything you can do about it.