Re: DTSTART for recurrence instances

Doug shot back on 12/05/2003 02:08:28 PM:
> > > > Section 4.8.4.4 Recurrence ID
> > > > . . .
> > > >    The date/time value (RECURRENCE-ID) is set to the time when the
> > > > original recurrence
> > > >    instance would occur; meaning that if the intent is to change a
> > > >    Friday meeting to Thursday, the date/time (RECURRENCE-ID) is 
still
> > > > set to the
> > > >    original Friday meeting.
> > >
> > > Meaning in the object being sent in the reschedule. In order to say 
X
> > > moves to Y,
> > > you need to properties to hold X and Y. So the above paragraph means 

> > send a
> > > new object with the new Y in RECURRENCE-ID and the old X in DTSTART.
> >
> > Lets not start this again shall we?  The original authors have even 
> > responded to this and they have clearly said that RECURRENCE-ID does 
> > not change on an instance reschedule.  The DTSTART for the instance 
> > can change on each instance reschedule but the the RECURRENCE-ID does 
> > not. 
> 
> 
> NO ONE SAID THAT IS THE TOPIC.

You appeared to be reintroducing that idea in this discussion.   At least 
thats how I take your comments given the citation you were responding to. 
Please do not use concepts that were already covered and the original 
authors have noted as being incorrect.   On instance reschedules 
RECURRENCE-ID is unchanging so using it as part of some X - Y or Y - X or 
other calculation is not viable.

As I noted in another reply, there is no iTIP text regaring the use of 
RECURRENCE-ID to calculate DUE values and thats likely due to the edits we 
made when we changed the design for RECURRENCE-ID. 

Thinking logically, if you tried to do some calculation based on a 
changing DTSTART and a fixed RECURRENCE-ID value then you can get a wildly 
changing and inaccurate DUE value.  For example, if you move the VTODO out 
a day the DUE date would move out 1 day.  If you then moved it out 3 more 
days your DUE date would be calculated as 4 days after the DTSTART rather 
than 1 day after it.  If you moved the instance backwards a few days in 
time, the DUE value would be miscalcuated as being before the DTSTART 
value.  Clearly this is not desirable.

Since the iTIP messages are full snapshots of the Organizers copy it would 
provide a DUE (or DURATION) value for the recipient to use if the 
Organizer had one.  If they did not, none will be present.  No need for 
mess or fuss and certainly no problem with not being in sync w/the 
Organzier.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...