> 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.
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.