Time Semantics: Getting it wrong is easy
Outlook, Appointments and Time Zones:
"To many people, Outlook really seems really bad at handling time zone changes, and that's being kind. This is in part because people don't understand that Outlook uses UTC time for appointments and adjusts the time using the time zone offset configured on the computer."
Translation: You're stupid. Learn to think like your computer!
"Note that this is not "an Outlook problem", as this is how computers, email clients and mail servers handle time zones."
Translation: Other programs work just like Outlook, and the programmers can't all be wrong. [Or can they?]
"Outlook does not support an absolute time option for the calendar, which would permit you to enter 2 PM and the appointment would always stay on 2 PM, no matter how many times you changed the time zone. It also doesn't have an option for ‘in what time zone?’ so that you could make an appointment for 2 PM and select Pacific time zone and it would show up as 5 PM in your calendar when the computer is using the Eastern time zone."
Translation: Ok, we fess up: The problem really does lie in the fact that Outlook uses the wrong time semantics.
The Moral of the Story: Even Billion-Dollar Corporations can get time semantics wrong.
Sometimes, you want timestamps that are invariant to nominal time, so that 3pm = 3pm, with the time not bound to any time zone at all. Other times, you want timestamps that are invariant to Universal Time--so that 2pm in San Francicso will be equal to 5pm in New York.
Sometimes, you want timestamps statically bound to a specified time zone, so that 2pm in San Franciso always is displayed as 2pm (even though the computer treats it as equal to 5pm in New York.) Other times, you want timestamps whose "local time" changes dynamically to match whatever time zone the user specifies as the "local time" of the computer--so that the time displays as 2pm when you've set the computer's time zone to San Francisco time, but displays as 5pm when you've set the computer's time zone to New York time.
Unfortunately, not only do most applications get this wrong, most date/time libraries don't support both nominal-time invariance and Unviersal Time invariance, nor do they support both timestamps statically-bound to a specified time zone and also timestamps bound dynamically to the current system time zone.
Chronos does it all.
No comments:
Post a Comment