Re: DTSTART for recurrence instances

[email protected] wrote:
> 
> Mark wrote on 12/08/2003 02:25:39 PM:
> > > 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'.
> 
> Dont bother trying to bait me into non-technical discussions or
> exchanging personal barbs.  I wont waste my time or the WG bandwidth
> on it.
> 
> If you actually read iTIP, it only says:
> 
> 4.5.7.2 Calculating due dates in recurring VTODOs
> 
>   The due date in a recurring "VTODO" calendar component is either a
>   fixed interval specified in the "REQUEST" method or specified using
>   the "RECURRENCE-ID" property. The former is calculated by applying
>   the difference between "DTSTART" and "DUE" properties and applying
> it
>   to each of the start of each recurring instance. Hence, if the
>   initial "VTODO" calendar component specifies a "DTSTART" property
>   value of "19970701T190000Z" and a "DUE" property value of
>   "19970801T190000Z" the interval of one day which is applied to each
>   recurring instance of the "VTODO" calendar component to determine
> the
>   "DUE" date of the instance.
> 
> There is no actual text for the "latter case" describing _how_
> RECURRENCE-ID would be used on a VTODO; just that "or specified..."
> bit that has nothing supporting it elsewhere in the text.  It was
> likely in a second paragraph that got removed before we went to Last
> Call.  One could take it to be "Well, I can just use the RECURRENCE-ID
> as the DUE value" however thats not valid because A) it could be
> BEFORE the instances DTSTART and B) the reschedule is a full snapshot
> so if it had no DUE or DURATION value then you should not be
> calculating one now.
> 
> If we had kept the delta RECURRENCE-ID model then a CUA could have
> done something like "diff between RECURRENCE-ID and new DTSTART" is
> how much the VTODO shifted and so the new DUE date can be calculated
> based on the old DUE date.
> 
> However this logic is useless now if you properly consider:
> 
> 1: Any initial VTODO wont have be able to calculate a difference
> between 2 versions of the VTODO since both RECURRENCE-ID and DTSTART
> at identical.  As such each VTODO instance will have the same length
> interval between its DTSTART and its DUE.
> 
> 2: On any reschedule of the VTODO instance, the Organzier would be
> sending a full snapshot of the VTODO and as such the recipient would
> be using that so they are in sync w/the Organzier.  If the Organzier
> did not include a DUE then who is the invitee to add one for them?
>  (They can if they want but its not a valid DUE value.)
> 
> 3: When dealing with multiple instances at a time, the DUE for each
> subsequent instance should be calculated based on the difference
> between the DTSTART and DUE (or DURATION) of the 1st instance of the
> affected subset, if provided (see #2).
> 
> 4: We did not opt for a delta RECURRENCE-ID model so its not useful in
> trying to do any shift calculations.  This coupled the above means you
> are inventing mechanisms or behaivour that is just not there or that
> is incorrect.
> 
> > 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.
> 
> Actually I think you are still under the mistaken impression that
> RECURRENCE-ID changes when the a component is rescheduled.

FYI - EVERY discussion about RECURRENCE-ID is not that topic.