If it's Tuesday, it must be 10 a.m.

SAN FRANCISCO (10/03/2003) - 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 (Request for Comments) 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, Mozilla Calendar, or any 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 Corp.'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.

The problem, as everybody who runs into this dilemma soon realizes, is that Outlook and iCal and most other calendar programs I've seen 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. That feature usually isn't needed, so should be hidden but easily accessible. It's 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.