Re: DTSTART for recurrence instances

[email protected] wrote:
> 
> 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.

Yes 2446 does, look for 'Calculating due dates in recurring VTODOs'.

> 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.


instance due date as described in 4.5.7.2 is:

  instance-due-date = RECURRENCE-ID + (DUE - DTSTART).

It is always correct.

Clearly you are using incorrect procedures as outlined in 2446.