[Ietf-calsify] What is the appropriate serialization for a recurring event with one event changed?

Simon Vaillancourt simon.vaillancourt at oracle.com
Tue Oct 4 07:14:27 PDT 2005


Hello Jeffrey,
   This is a bug in our product where we don't add an RDATE to the main 
event (It's already on our todo list). You should have seen something like :

DTSTART;TZID=US/Pacific:20051003T090000
RRULE:FREQ=DAILY;COUNT=5
EXDATE:20051005T160000Z                #Wednesday at 9AM PDT (in UTC)
RDATE:20051005T180000Z

the other VEVENT has

RECURRENCE-ID:20051005T180000Z         #Wednesday at *11AM* PDT (in UTC)
DTSTART;TZID=US/Pacific:20051005T110000


As far as "Is an EXDATE appropriate for the original time if an event's 
time has been moved?".  Ideally, the meeting you store on a CalDAV 
server would remain unchanged when you retrieve it later on, but when 
plugging a CalDAV interface on top of an existing calendar store(Like we 
do at Oracle) it's a different story. For the Oracle product, we 1) 
Convert the iCalendar meeting to our internal format, 2)Do a diff of 
both meeting representations and send the detected changes to our 
calendar backend.  This conversion and diff process might explain the 
differences you see between the meeting you put in and the meeting you 
retrieve later on. I'm sure many would argue that "moving" a recurrence 
vs "deleting and creating" a recurrence is very different even if the 
expanded end result in a standard calendar UI is the same,  that's why 
we're still working on perfecting our diff and conversion algorithms.

Regards,
Simon

Jeffrey Harris wrote:

>Hi Folks,
>
>I've been working a bit with Oracle's CalDAV server and Apple's iCal,
>and they have pretty different behaviors when serializing a recurring
>event with a change to one event.
>
>Lets take, for example, a daily event, starting Monday at 9AM, last
>occurrence Friday at 9AM.  If I change Wednesday's event to 11AM, what
>should the resulting stream look like?
>
>iCal exports this as two VEVENTs, one has (omitting lots of other lines):
>
>DTSTART;TZID=US/Pacific:20051003T090000
>RRULE:FREQ=DAILY;COUNT=5
>
>the other VEVENT has
>
>RECURRENCE-ID:20051005T160000Z          #Wednesday at 9AM PDT (in UTC)
>DTSTART;TZID=US/Pacific:20051005T110000 #Wednesday at 11AM PDT
>
>Oracle's stream also has two VEVENTs:
>
>DTSTART;TZID=US/Pacific:20051003T090000
>RRULE:FREQ=DAILY;COUNT=5
>EXDATE:20051005T160000Z                #Wednesday at 9AM PDT (in UTC)
>
>the other VEVENT has
>
>RECURRENCE-ID:20051005T180000Z         #Wednesday at *11AM* PDT (in UTC)
>DTSTART;TZID=US/Pacific:20051005T110000
>
>Is one of these more correct than the other?  Is an EXDATE appropriate
>for the original time if an event's time has been moved?  What does it
>mean for a RECURRENCE-ID to reference a time that isn't already in the
>recurrence set?
>
>Sincerely,
>Jeffrey
>_______________________________________________
>Ietf-calsify mailing list
>Ietf-calsify at osafoundation.org
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>  
>



More information about the Ietf-calsify mailing list