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.

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.

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.

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 :-)

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!

@Ian Jones: some do let you put ‘recurs forever’ items on the calendar, but they’re a pain to deal internally sometimes.

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.

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.

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?