There are many misconceptions around how time should be handled in calendar applications. In some other context I care about clock synchronization with microsecond accuracy; for calendar events I would be happy if programs were not off by an hour… So let me write up my thoughts and examples in a blog post that I can link to each time some of these issues come up.
Time zone definitions + UTC
Coordinated Universal Time (UTC) is the lingua franca used to express time all across the globe. It is the time which tracks the rotation of the Earth as observed at the Royal Observatory, Greenwich, London. It is still sometimes casually called “Greenwich Mean Time” (GMT), or “world time”. If UTC is the lingua franca, then time zone definitions are the Babel (and bane) of calendar applications.
In the simple case a time zone only specifies a fixed offset against UTC: a positive value is used for locations east of Greenwhich. Subtracting that offset from a local time gives the corresponding time in UTC. Offsets are typically full hours, but half or even quarters of an hour are also used. In the more general case, a time zone also defines when daylight saving time (DST, aka summer saving time because it occurs during the summer) is active. During that period the offset against UTC is usually larger by one hour more than during the normal time in the winter.
The “wonderful” invention of daylight saving time primarily demonstrates one thing: time zones are defined by human laws, not laws of nature. They can and do change, as anyone living in or working with the US experienced in 2007. This was not the only case, but it certainly was the most prominent one which required software updates and revealed shortcomings in the time zone handling of a certain software that readers of this blog might be familiar with…
So how should this mess be dealt with?
Represent all time stamps in UTC without time zone? No!
This is by far the most common suggestion. The argument usually is that if all software used UTC exclusively to communicate time stamps, then there would be no misunderstandings. There’s just one minor drawback: it doesn’t work in several real situations. Let me give examples.
Changing DST Rules: suppose you are setting up a lunch meeting in London on Monday, March 30, 2009, at noon 12:00am. Your software stores that as “11:00am UTC” because daylight saving time is active then. Later on the UK decides that daylight saving time wasn’t such a good idea and cancels the whole transition to it in 2009 and all following years – hey, one can always hope. For a more realistic argument assume that the day of the transition is changed so that DST is not active yet on March 30, 2009. The day of the meeting comes, the calendar software faithfully translates “11:00am UTC” into “11:00am London Time” (zero offset now!) and you are one hour early for the meeting. In other situations you would have been one hour late. Now this example might be dismissed as “unlikely”, but it has happened and can happen again. Also, shouldn’t we at least try to design software that gets it right in 100% of the cases that we can think of? There are enough chances to mess up later on during the implementation…
Recurring Events: here’s another, more common example where using UTC without information about time zones fails. I present it as the second example because it is more complicated. Suppose you are a German member of an international team and the weekly team meetings are scheduled to take place each Monday at “8:00am Los Angeles” time. Los Angeles is normally 8 hours behind UTC and 7 hours during DST. When converting to UTC, which offset should be used? Remember, the meeting occurs throughout the whole year. It doesn’t matter, both choices will be wrong. Suppose that always the standard offset of -8:00 hours is used, giving us a recurring meeting on Monday stored with start time “16:00pm UTC”. The German colleague schedules another recurring weekly meeting at “17:00pm German Time” for Tuesday. With the normal German offset of +1:00 that also translates to “16:00pm UTC”.
Now on Monday, March 9 2009, the colleagues in Los Angeles reapply the standard -8:00 offset (because that’s how their software works) and happily meet with their colleague at “8:00am Los Angeles Time”. The next day they do the same, but note that the US already has DST while Germany doesn’t. Therefore “8:00am Los Angeles” corresponds to “8:00am + 7:00 = 15:00pm UTC”, which is “15:00pm + 1:00 = 16:00pm German Time”. That’s not the time when the meeting was supposed to take place. Software that works like that forces all users to stick to daylight saving times of one particular location.
Conversion to and from UTC using the time zone of the current user won’t work either. It’ll just lead to different kind of errors, for example when a meeting scheduled in the US is converted to German time. Without the information of the pertaining time zone attached to the time stamp these kind of conversions are impossible to get right in all cases. When two semantically different events are stored in the database using the same bits and bytes, then the original intention cannot be restored from this information alone.
Represent all time stamps in UTC with time zone? No, use relative time instead.
So is adding the time zone information going to change anything? It’s better, but still not perfect because everyone must agree on which offset was used to convert the initially local time stamp into UTC. Is it the offset when the meeting is created? The offset at its first instance? What if the offset includes DST and the rules for DST change later on? All of these problems go away when the time stamp is stored as intended by the user, together with the time zone in which it is defined. Then the conversion to UTC and from there into another time zone can always be done on demand, using the then current time zone rules.
Using local times
Using local time stamps without time zone information, like “8:00am”, is so obviously wrong that I am only listing it for the sake of completeness. Suppose someone in London says to someone in Berlin “let’s have a phone call at 8:00am” – does that mean 8:00am in London or Berlin, which are one hour apart? Humans cannot tell without further information; neither can software. Unfortunately it is really the only information that some software stores.
If you think that there is a solution which works without storing times relative to a time zone, then let me know how it works, either in the comments or by email. I bet you a beer that I’ll find a situation where it fails. I’d be more than happy to pay a beer for learning how to accomplish such a trick
What I haven’t covered is how different software can communicate time zone information. That’s something for another post.