»They got time all wrong, and a calendaring exercise proves it«

Today, I started a small project to export Outlook Data as  iCalendar file. In the process, I successfully managed to create a iCalendar file that can be read by Apple’s  iCal, including repeated events and such.

However, once the script correctly output events that span a year or so, I started seeing events that took place either too early or too late. After some thinking (Yo, I’m not so smart, you know) I found out that the date/time format I was using in my export was flawed.

I used the UTC notation which does not account for daylight savings, and thus events that span daylight savings and no-daylight savings (e.g. staring in June and repeating, e.g., until today) got shifted by one hour.

Tonight, I did some more research and found this very  interesting article by Jon Udell. I feel I could’ve written the first phrase …

I’ll spare you the details of my excursion into  MAPI (Microsoft’s mail API), using Python’s Win32 and COM extensions, plus code I cribbed from the SpamBayes plug-in for Outlook. Suffice it to say that after some fiddling, I got Outlook to disgorge my events as iCalendar VEvent records. Then the fun began. My calendar for October includes several trips to other time zones. Some of those occur before the end of Daylight Saving Time, and others after. Those of you who travel more than I do have already guessed what dilemma now arose. Outlook’s COM interface handed my Python script a UTC time object, and another field with my time zone, which it reported as GMT-05:00 Eastern Time (US and Canada). How should I represent that time in my published calendar? Here’s one choice for a 10AM appointment on October 15:DTSTART;TZID=US/Eastern:20031015T100000 But wait! That appointment is in Denver. Maybe I should publish the UTC time: DTSTART:20031015T150000Z In fact, both approaches are lame. The first looks right to me in Outlook now, will even look right to me in October (since I tend to leave my computer on Eastern Time when traveling), but is wrong from every other perspective. The second fails to account for Daylight Saving Time. So, for example, a 10 a.m. before the last Sunday in October will show up (on my local calendar) as 11 a.m.

At least I know why my script failed – I guess I will simply ignore the fact that there exist other timezones than CET.