Posted December 27, 2010

CalConnect, as you learn from our web site, /, “is focused on the interoperable exchange of calendaring and scheduling information between dissimilar programs, platforms, and technologies. The Consortium’s mission is to promote general understanding of and provide mechanisms to allow interoperable calendaring and scheduling methodologies, tools and applications to enter the mainstream of computing.”

We encourage, promote, and provide assistance in doing the “right thing” with respect to interoperable calendaring. Sometimes, however, doing the right thing is not quite enough you need to do the right thing the “right way”. A recent example helps illustrate this point.

In the U.S., athletics are a big part of the collegiate experience, unlike most other parts of the world. Most of the biggest collegiate athletic programs now outsource their athletics web sites, even when the college’s other web sites are hosted locally. These athletic web sites are hosted by a handful of vendors specializing in this work. These web sites are designed to look like the most popular professional sports web sites, and depending upon your age, and your aesthetic sensibilities, you find these sites either energizing or enervating.

I work at a university that uses an outside vendor to host and manage our athletics site. Recently, to understand how our capabilities compared, I unscientifically surveyed the athletics schedules at top programs in basketball and football. I was looking for the ability to download an iCalendar (RFC 5545) format (.ics file) of the schedule, and/or subscribe to an iCalendar feed of the schedule, which amounts, more or less, to the same thing.

Not all web sites provided the schedule in iCalendar format, but for those that did, I assumed that I would have no trouble importing and displaying the schedules in other calendaring systems, desktop or “cloud”. Jon Udell, in his recent talk at Harvard’s Berkman Center for Internet & Society, reminded us that “¦ iCalendar is the RSS of calendars. It can enable a calendar-sphere in which, as in the blogosphere, everyone can publish their own feeds and also subscribe to feeds from other people or from network services.” Nonetheless, what I discovered surprised me.

I downloaded an iCalendar file (.ics) for a contest between a college in the western U.S. and a visiting team from the eastern U.S.. It was displayed on the web site of the visiting eastern team as starting at 8:00 PM, not the local California start time of 5:00 PM. However, because the events were represented in UTC, one of the 3 time formats defined and supported in RFC 5545, when imported into other calendaring systems (such as Google, Yahoo, Outlook, etc), the event was displayed as starting at 7:00 PM eastern, which was not the correct time at start time for the event or relative to the local time of the visiting team . This was because the iCalendar data was generated using an incorrect UTC date and time offset. This is an easy error to make as in those places which observe daylight saving time (DST), the UTC offset is not constant throughout the year. Since most events are specified as a local time in a particular timezone, it is far better to generate iCalendar data in that same way as that eliminates the possibility of errors such as the one illustrated here.

When I downloaded and imported an .ics file schedule of another university from their web site, produced by an even larger vendor, another problem emerged. The iCalendar file did not represent timezone information properly, which resulted in all the events being interpreted as “floating time”, another of the supported RFC 5545 time formats, although the intent, upon inspection of the .ics file was to be in ˜local time with timezone reference, the third and most relevant time format in RFC 5545. Floating time (also referred to as local time), “represent(s) the same hour, minute, and second value regardless of which time zone is currently being observed”. Floating time might be appropriate, for example for a jogger, who religiously blocks out 6:00AM 8:00 AM for her/his morning run every day, independent of where he/she may be, whether it is a weekend, holiday or anything else. However, this is not true for an athletic contest, which has a specified starting time in relation to a specific timezone. When I imported these events into other calendaring systems, they were the same local time everywhere, making them incorrect when displayed in calendaring systems almost everywhere.

In both cases, the format of the .ics was conforming enough to allow them to be imported without error into other calendaring systems. However, the semantics, of these .ics representations were not conforming to the event organizer’s intent informing people when these events were to start. Date and time information needs to be stored as completely as possible with as few assumptions about the context as possible, for both internal consistency and interoperability across online calendaring systems. This means almost always representing event information in the RFC 5545 “Local time with timezone reference” format.

Calendaring standards and formats are just a means to an end making our events more successful through stronger attendance, creating publicity for the event or sponsoring organization, or bringing distinction to the sponsoring organization. In order to achieve these objectives, we need to ensure that our meaning and intent are conveyed properly across calendaring system boundaries.

It is well worth your while to run through the exercise of exporting your public events, and importing them into the more widely used calendaring systems to ensure that you have, indeed, done the right thing the right way.

Gary Schwartz
President, The Calendaring and Scheduling Consortium