Thanks to my calendar syndication project, I’ve gotten intimately familiar with how various calendar programs — including Outlook, Google Calendar, and Apple iCal — handle the entry of recurring events. They all make the task reasonably straightforward, but there’s one vexing problem. There isn’t a way to specify exceptions. My local YMCA, for example, is closed for maintenance during the last week of August. You could enter a “YMCA closed” event for that week, and hope that it gets rendered so that people will understand it to override all the recurring events shown for that week. But that’s not a great workaround.
Really, you’d like to be able to specify exceptions as part of the recurrence rule. To do that in a standard way, that capability would have to be part of the iCalendar standard. And sure enough, it is:
Property Name: EXRULE Purpose: This property defines a rule or repeating pattern for an exception to a recurrence set. Property Name: EXDATE Purpose: This property defines the list of date/time exceptions for a recurring calendar component.
But none of the calendar programs I’m familiar with seem to support these features as part of event data entry. Are there others that do? Even if there are, I couldn’t depend on the feature being ubiquitously available to folks who contribute to the calendar network I’m trying to assemble.
The service operates as an iCalendar intermediary, though, so it might be able to inject some exceptions — at least for global EXRULEs like “YMCA closed last week of August”. It’d be harder for event-specific EXRULEs like “Pool closed for maintenance July 22″ which would affect a subset of events, or “Kickboxing class won’t be held Sept 14 or 18″ which would affect a single event.
One of the questions this project has led me to ponder is: Why, after all these years, are calendar programs not used as extensively as it seems they should be? Maybe this is part of the answer. Exceptions to rules are part of the fabric of real life. If the software doesn’t enable people to specify those exceptions, that’s a problem.
Update: Thanks to commenters for pointing out that of course calendar programs enable people to specify exceptions. They just don’t do it the way I expected, i.e. as a continuation of the dialog used to specify the recurrence rule. Instead they do it by enabling you to edit or delete a single event in the series, after the series has been created.
Now I’m curious as to whether my expectation is a geeky aberration that hasn’t affected most people, who have been happily creating exceptions all along. Or whether it’s broadly undiscovered by civilians too.
August 28, 2008 at 10:26 am
I’m sure Outlook supports exceptions, when editing a recurring event you get a dialog asking if you want to edit the series or that instance – I know because I used it when my state government introduced DST with 10 days notice. Not part of your test-set I know, but Bedework supports exceptions, however Lightning doesn’t always display them when accessing via CalDAV. The Mozilla calendar in general claims to have supported edits to individual occurances since 0.3. I can’t work out if iCal supports it or not, my search-fu has failed (and I don’t have a Mac).
August 28, 2008 at 10:40 am
I recently discovered the tool remind. It runs on Linux and Mac OS, and Windows under Cygwin. Its worth a look.
August 28, 2008 at 10:52 am
I think you need to read RFC2445 a bit closer.
August 28, 2008 at 11:01 am
Outlook and iCal.app both support exceptions. Eg in iCal.app you set the regular RRULE which displays as n-events in the view. You can then move or delete individual instances of that recurring event. This creates appropriate iCal VEVENTs with EXDATE properties.
But you are right, most clients do not allow to set exceptions during the initial creation of the rrule. Its usually a two step process (create the event, then delete/edit the exception).
August 28, 2008 at 3:48 pm
Google Calendar supports the EXRULE, EXDATE for import and export but the standard client does not use them see http://code.google.com/apis/gdata/elements.html#gdRecurrence so you cannot just do a Quick Add of “Meeting every Tuesday from September 1st to December 1st except September 9th” but you can use the API to do the equivalent and include EXRULE etc
August 28, 2008 at 4:53 pm
> I think you need to read RFC2445 a
> bit closer.
I have. That’s where I quoted EXRULE and EXDATE from. The question was how to access the feature in clients.
Which question has now — thanks everybody — been answered.
> It’s usually a two step process (create
> the event, then delete/edit the
> exception).
Of course! *dope slap*
So, is my non-discovery of that feature is an example of geek vs civilian thinking?
I’m familiar with declarative ways of doing things, and I expect things to be consistent, so my strong assumption was that you’d specify an exception in the same way you’d specify a recurrence rule.
But maybe it’s more natural for a civilian — for whom direct manipulation is the more familiar mode — to distinguish between the two cases and expect to handle them differently?
August 28, 2008 at 10:20 pm
I guess exceptions are hard to predict in advance – it’s much easier to see conflicts once the event exists. Bedework offers the option of setting exceptions during event creation, but the UI is hardly intuitive. Which I think is the real reason – how do you easily manage 50 events (which is just a weekly recurrence for a year) in the add event dialog without making it a UI nightmare?
August 28, 2008 at 11:29 pm
> I guess exceptions are hard to predict in
> advance – it’s much easier to see
> conflicts once the event exists.
FWIW I’m not thinking about personal calendars here, but instead public calendars — the YMCA example is a good one — where the rules and exceptions are known in advance.
> how do you easily manage 50 events
> (which is just a weekly recurrence for a
> year) in the add event dialog without
> making it a UI nightmare?
Well you wouldn’t. The EXRULE for “except Thursdays between DATE and DATE” or the EXDATE for “except DATE” needn’t involve enumerating all instances, these are compact rules to write down, and it seems like they could be specified in the same way as recurrence rules.
But point taken. The expando UI already required for recurrence is challenging enough, this would take it a step further and that might be a step too far.
It’s just plain tricky when you get down to it. Specifying “except Sept 1″ is more easily done by deleting the Sept 1 instance of an enumeration — /if/ you’ve internalized the two-step tango required to a) write a rule, and then b)edit/delete an instance.
Specifying “except Thursdays in summer” would require you to delete a bunch of instances, and at that point you’d probably wish the expando UI for recurrence could expand far enough to let you write that rule.
Both methods could be made available, of course, but clearly the specification of complex exceptions isn’t a broad enough use case to have warranted going that extra mile. Which is understandable I guess.
August 29, 2008 at 8:13 am
One thing that calendar apps don’t seem to do, which does match real world – is let you edit events that recur for ever.
It’s common to want to delete an appointment from now on. Changing the recurrence tends to deleted existing exceptions (so history is lost).
Likewise changing the time of a meeting permanently will change historic entries.
From a MS point of view, this may have changed since Outlook 2003 – but had unnatural behaviour in that & previous versions.
Some PDAs used to work this way. After all their focus was as a diary, but I don’t know current state of play.
August 31, 2008 at 9:57 pm
I think I’ve posted this before, but for calendar interoperability, track the Calendaring & Scheduling Consortium
@Ian Jones: some do let you put ‘recurs forever’ items on the calendar, but they’re a pain to deal internally sometimes.
September 3, 2008 at 8:35 pm
hey,
Not trying to be too snarky here — I certainly found the comments on this blog posting informative and interesting — but whether attributable to geek-thinking or ‘civilian’ thinking (a somewhat bizarre militarization of the ‘geek’ frame btw), I do have to wonder how you could have read through an entire RFC yet somehow missed having the pragmatic experience of actually changing the time in one iteration of a recurring event, which is usually when you’re prompted to create an exception or a rule in any calendar program..?
T’would seem you live an exceptionally ordered life wherein monthly meetings and so on never have to be rescheduled, or a perhaps a more chaotic one in which there are no recurring events (to change single iterations of.) Or perhaps you were highly sleep-deprived when you wrote this? That often leads me miss the forest for the trees as well.
Still, an informative conversation, and thanks for unearthing that rule…I was looking for it!
September 3, 2008 at 10:35 pm
The bigger calendaring issue is getting anniversaries/birthdays recorded against calendar days and having them immobile with respect to timezone changes.
September 4, 2008 at 9:20 am
> yet somehow missed having the pragmatic
> experience of actually changing the time
> in one iteration of a recurring event
I’ve certainly deleted one instance from a recurrence set at some point, though I never had occasion to look at the generate iCal and see the EXDATE element included there as a result.
What happened here was that I had some event sets for which the rules and the exceptions were all known in advance. It seemed logical to express all that in one place.
>Or perhaps you were highly sleep-deprived
> when you wrote this?
That could be true too :-)
December 8, 2008 at 6:18 pm
Even more vexing than the recurring meeting issue discussed above is the limitation of Outlook 2003 Calendar to:
– to see all instances of a recurring meeting in a list format showing date and time
– to schedule a single ocurrence of a recurring series on a different day and/or time to allow for holidays or other’s availability
My group is migrating from Oracle’s deadended Corporate Time (CT) to Outlook Calendar. The quirky workarounds I’ve used in CT for years don’t seem as evident in Outlook.
December 21, 2008 at 3:53 pm
I use gmail for all my calendar needs and it handles exceptions gracefully. I think if you were to introduce exceptions to the creation dialog it would make it way to bulky – not to mention that general exception rules are not easy to comprehend even in human language: i think a lot of people simply wouldn’t know how to specify the exceptions and would need to find the specific dates afterwards and delete them anyways.
What i love about gmai is that its so freaking quick to setup an event and then you can always modify it later when you have time.
February 19, 2009 at 2:41 pm
I share your pain!! I maintain a calendar at a school with many daily recurring appointments and events. Come summer and I would like to have a clean calendar for a few months. The way outlook is I have to either set the end date for the last day of school and then create new events for the beginning of the new school year OR spend the time deleting every occurence that is scheduled through the summer months. I have found that clicking on the first event I want to delet, hitting delete, hitting enter (agreeing that it is okay to delete), then hitting tab (which highlights the next event) is a tedious but efficient way to delete them without a billion mouse clicks.
June 16, 2009 at 11:54 am
Interesting. Reading your post helped me figure out how to schedule conference rooms.
While it’s inconvenient, but possible to schedule a series and then delete/edit the exceptions, the problem becomes trickier if resources are scheduled through Outloook on a series. Exchange will auto-decline the series if there is even a single conflict. With the auto-decline you don’t get an opportunity to edit in the second pass. Extremly annoying.
Reading this I figured out a sequence that works (but makes it a lot harder than it should be):
- Schedule the series with the resource that works most of the time.
- It will get auto-declined, but the decline will list the conflicts.
- Now go to the dates of the conflicts and remove those occurences, to establish a non-conflicting series.
- Add the resource back in and send the update (which now honors the exceptions) and will be accepted.
- Schedule an independent meeting for the dates of the conflict. It will not be connected to the series as an exception.
- Ideally do this before any of the participants are added to avoid spamming everyone’s inbox.