In 2000 when I founded JigZaw my goal was to build a calendar which would update itself (follow the link to see what we built as the interface). As part of my research into calendaring I joined the IETF Calendaring and Scheduling Working Group and became an active participant in the building of calendaring and scheduling standards, though my personal and professional focus was on the calendaring aspects of the standards. I even briefly became a co-editor of the iCalendar standard (RFC 2445).

More recently I have had many conversations around calendars with people here in the Bay Area. There is a renewed interest in working solutions to the many complex issues around calendars. And while I appreciate the UI enhancements of web 2.0 calendars, such as 30Boxes; there are some fundamental challenges which calendars, calendaring and scheduling face that need to be addressed.

So, in this piece I will outline these issues, define the distinctions between calendars, calendaring and scheduling, and, I hope, offer some suggestions for where to go next. As a consultant, I am available to assist anyone who is interested in further exploration of these issues and am open to licensing the php code libraries we have developed.

Definition of terms

Calendars: A collection of events organized on a time scale. Technically, an iCalendar object also includes many other types of objects (Journals, ToDos, Alarms, Timezones) as well as events. Practically, most people focus on a calendar as a collection of events and reminders, some repeating, some defined specifically. In most practical implementations, the calendar also has characteristics such as a native timezone (defined in some way) and is typically associated with someone (or a group).

Calendaring: The process of managing a calendar or collection of calendars with a focus on the capture of past, present and future activities. Most individuals and organizations use calendars in this way, as a record of what has happened and a collection of notes and reminders about the future (birthdays, holidays, future events).

Scheduling: To coordination of multiple calendars. The typical example is the organization of a meeting between multiple people (and at times resources such as a room). Within organizations this use of calendars is common, but in the modern outsourced and contracted workplace, scheduling is an increasingly complex activity. Much of the complexity of the iCalendar and related standards involve the aspects required to handle scheduling requests, workflows, and negotiations.

Summary of the Challenges of Calendars, Calendaring and Scheduling

I will mostly focus on calendars and calendaring. There are both technical and non-technical challenges, first I’ll cover the technical complications, I will cover the many social issues in a later post.

Technical.

1. Timezones. There is no standard for timezones (the data) nor will there likely ever be one. This is because timezones are a political matter, decided by a complex combination of political bodies. In the US timezones are determined by local mandates, state laws, and federal decisions. Timezones also require some degree of geospatial knowledge. Few calendars handle the true full range of timezones (all parts of Indiana for example) and fewer still maintain their databases as political decisions change the rules (infrequent but for example the US Congress recently changed the rules of Daylight Savings Time which, in turn, impacts timezones). Even more complexly, how timezones are named is also non-standard making the mapping of timezones complex at best.

2. Daylight Savings Time. Closely related to timezones, the impact of Day Light Savings time is that it breaks and renders complex what usually seems simple.

To illustrate some “simple” questions (answers below):

“How many hours in the day?”

“If an event starts at midnight and goes for three hours, when does it end?” and the related question “If an event starts at midnight and ends at 3 am, how long did it last?”

“If an event occurs every night from 9pm to 9am, how many hours did the event take up last week?”

The answer to all of the above is “it depends”. In no case is there sufficient information to answer, and indeed there are many further questions to be explored.

First, what day of the year is it?

Second, where are you (the person answering) and what timezone rules do you follow?

Third, for the last question, a religious question, when does the week start and end. Ask this even in the US and you may get very different answers (usually “starts on Monday, ends on Sunday” but not always - in countries where the “weekend” is Friday/Saturday such as most Muslim countries and Israel and more typically you might hear Sunday to Saturday)

Fourth, you are implying and assuming that the event starts and ends in the same timezone, under the same set of rules.

Most, though not all, calendar software assume that defining the start of an event and the end time OR the start time and the duration to be the SAME event, but there are at least two times in a year (if Day Light Savings is honored) when this is not the case. Likewise, most calendar software have an inbuilt assumption that “one day = 24 hours”. As far as I am aware, no software (or the relevant standards) support defining an event as a duration and a fixed END time, though this is a logical option. And there is no standard set of rules for how to handle the mismatch of assumptions under the special cases of day light savings.

3. Leap years. Most calendars handle leap years, and for the most part, handle the complex set of exceptions for the century and every 400 centuries. But nearly no (none that I’m aware of) handle leap seconds. These seconds are a semi-political act (scientists decide when they have to be used, but politicians somewhat control if they are implemented). For most use cases of calendars (and even scheduling) this degree of inaccuracy is acceptable, but any system which is built with the assumption that all minutes last 60 seconds exactly - and from that assumption build up math about how many seconds in an hour etc, is broken when leap seconds get implemented.

4. Reoccurring events. While most calendars on the market today handle some subset of reoccurring events, even the standard (iCalendar) has complex issues around reoccurring events. The complication is how (and if) it is possible to determine if the recurrence rules trigger the occurrence of an event - and what data is needed to calculate this, as well as how special circumstances get resolved (for example, daylight savings time). It is possible under the rules of iCalendar to define very complex conditions and criteria for recurrences, which may depend on a wide array of assumptions. More basically, the issue with reoccurring events is how do you store (and then pull up) the events. While the standard does NOT define a data storage (just the data interchange definitions) clearly something special has to be done with reoccurring events, in particular events which appear (at least) to reoccur infinitely (holidays and birthdays are two fairly simple examples).

5. How do you handle a flight? This is often a subset of the issues around timezones, in effect a flight is an event which starts in one timezone but ends up in another (perhaps with the further special case that the “local” timezone may change at the end of the event, however in the case of a flight on a calendar but not depicting the calendar “owner” (more on that concept shortly) this may not be the case. Flights (or other travel which crosses timezones) illustrate another “gotcha” which many (most?) calendar software developers run into.

6. Whose calendar is it? And from that, how do you define identity, and what is bundled around the “owner” identity vs. the “calendar” itself (for example do you have to define the calendar’s native timezone differently from the timezone “of” the calendar owner?

7. How (and if) do you handle events which do not include a timezone. A usecase of this would be putting on your calendar that lunch is always at noon (not noon in the timezone when you enter the event, but noon no matter if you later change timezones) or that a holiday or birthday is always on that specific DATE not that date when it happens in a specific timezone. (think of New Year’s Day, logically it starts at just past midnight on Dec 31st in the timezone currently in).

8. Accuracy. While calendars are usually relatively speaking accurate in the immediate term, no calendar system (at least that I am aware of) handles historical time well. Handling changes in the rules of daylight savings time or timezones for example, or correctly helping answer the questions that arise around the historical facts of the transition from the Julian to the Georgian calendars. Nor do many calendars handle astronomical time well, or time much past 2037 when the Unix timestamp rolls over. And as I noted above, calculations about hours in a given period (or the number of seconds) depend on political dimensions and location.

Next post, a discussion the key issue for calendars and calendaring - not technical complications but the social issues around how we use, think about, and interact with (or not) our calendars.

This entry was posted on Wednesday, March 8th, 2006 at 3:28 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.