Re: DTSTART for recurrence instances

[email protected]
Newsgroups gmane.ietf.calendar
Message-ID <OF6A42C7EF.CBECFB32-ON85256DF7.00523ABA-85256DF7.0053C0AD@notesdev.ibm.com>
Mark replied on 12/08/2003 06:04:55 PM:
> > > 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.

I suggest you learn to distingush the role of instance _identifier_ 
(RECURRENCE-ID) from instance _start_date/time_ (DTSTART) when you propose 
algorithms then.  You (and others) continue to misuse RECURRENCE-ID and I 
will continue to try and disavow you of that mistaken idea.

RECURRENCE-ID is strictly used to find and identify the correct repeat 
instance of a repeat set.  Its intended to help both sides of the workflow 
process correctly identify the instance in question.  It is NOT designed 
to be anything like "the instances last DTSTART time" as this makes 
dealing with missequenced or lost workflow messages impossible (or at 
least waaay to cumbersome). 

DTSTART is used to specify when the instance starts.  When an instance 
first gets created this value is assigned to the instances RECURRENCE-ID. 
As the instance gets rescheduled though, only DTSTART changes.

As such, your proposed algorithm would generate wildly varying and 
inaccurate DUE values depending on how far the instance gets rescheduled 
from its original DTSTART value.   As noted before, you could even get DUE 
values before the DSTART value of an instance and thats hardly acceptable.

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...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.