Part of working with calendars is working with timezones and – dare I say it – daylight savings time (DST for short). A calendar program/service/API that doesn’t support timezones, are able to used named timezones and thus handles DST is worthless. Naming timezones is really key to all of this as a timezone like GMT+1 doesn’t mean anything and cannot be used to anything meaningful. Why? Well for one there is no indication of whether we’re in the Northern Hemisphere or in the Southern Hemisphere – in the former it’s winter and the latter it’s summer. Believe it or not but it actually affects whether daylight savings, or summer time as it’s often referred to, is in effect.
Now that’s why naming timezones make sense. In Java for instance timezones are normally named by the city or region it affects. For instance I would normally use Europe/Copenhagen or at least Europe/Paris as the countries in the European Union switch at the same times. Lotus Notes, or Java in Notes to be exact, actually report my timezone as Europe/Paris when I ask it. Now this makes sense as this timezone incorporates information on the UTC offset, whether or not DST is observed and if it is when the switches occur.
But that’s actually not enough. Why?! Well because time point in time where DST changes occur may change over time. So actually a calendaring system needs to know when changes occurred in the past and when they will occur in the future. For instance Chile is postponing the switch to DST by two weeks in 2011 with extremely short notice (Chile Extends DST Due to Energy Crisis, IBM Technote 1470631: Chile extends daylight saving time two weeks in 2011). And only in 2011. If you’re working with people from Chile and scheduling meetings in this period there is a big chance things will go wrong.
You might remember that the US also changed the rules the DST dates was calculated some years ago to standardize across the states but it is still a very local decision as whether to use DST or not. It’s actually down to the county to decide. Take a look at my favorite example Indiana and see how confusing it is.
So while timezones and DST rules appear simple they are anything but and it’s why calendaring is hard.
And the timing of this blog post isn’t coincidental. The US – where DST is observed – changed to daylight savings time on Sunday 13 March where as we wont make the switch in Europe until 27 March.
One thought on “Why calendaring is hard”
Very true. One could add that it is even harder for the "classic" Lotus Notes/LotusScript developer, since there is little to no support for time zones in Notes BE classes. If you want (or need) to handle time zones properly, you’ve got to roll your own classes.
Comments are closed.