A long-ago friend who was the alpha math/science geek in our junior high school used to set his watch by the stars. If programmers had their way, we'd all use astronomically-pure sidereal time. Or at least we'd abandon the absurd notion of time zones. Daylight Saving Time? Don't even go there. I have seen world-renowned software architects go ballistic when that hated subject comes up. Look at the ill-disguised contempt in the IETF's RFC 3339, Date and Time on the Internet:
All times expressed have a stated relationship (offset) to Coordinated Universal Time (UTC). (This is distinct from some usage in scheduling applications where a local time and location may be known, but the actual relationship to UTC may be dependent on the unknown or unknowable actions of politicians or administrators. The UTC time corresponding to 17:00 on 23rd March 2005 in New York may depend on administrative decisions about daylight savings time. This specification steers well clear of such considerations.)
This week, Ray Ozzie touched off a cross-blog discussion by asking why we don't yet have a standard way to exchange "virtual objects so basic as calendars." His comment inspired me to dust off a back-burner project to export my Outlook calendar in iCalendar format (RFC 2445), so that users of Apple's iCal, or Mozilla Calendar, or other iCalendar-aware programs could subscribe to it. Along the way I rediscovered why calendaring, though indeed basic, is far from simple.
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 timezones. (For good measure, some occur before the end of Daylight Saving Time, 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 timezone, which it reported as GMT-05:00 Eastern Time (US & 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. So while it looks right to me in Outlook now, it's wrong for people in Denver. Alternatively I can set Outlook's timezone to GMT-07:00, record the event, and then switch back. Now the appointment will be right for people in Denver, but wrong for me.
The problem, as everybody who runs into this dilemma soon realizes, is that calendar programs typically don't allow you to distinguish between the location of the event you're scheduling and the location of the computer you are using to record the event.
When a computer in one timezone schedules an event in another timezone, the computer doing the scheduling needs to be able to accept and display both. Since the feature usually isn't needed, it should ideally be hidden but easily accessible. That's admittedly a thorny user interface problem. I'm sure programmers could solve it -- if they weren't so indignant about humanity's perversion of astronomical time. And now, if you'll excuse me, I've got to go. It's 0100 UTC and the sun's coming up.
Former URL: http://weblog.infoworld.com/udell/2003/10/06.html#a819