Earlier quoted context omitted.
I thought the solution to datetime was almost always to use TAI plus a library to convert for display in the UI. (Or UTC and accept that leap seconds might cause bugs.)
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 t…
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.