Re: DTSTART for recurrence instances

Doug replied on 12/03/2003 03:55:35 PM:
> > RFC 2446 - 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.
> >
> > Even if the text mention the original DTSTART as the reference point, 
> > it does not mention the actual value of the DTSTART/DUE values in an 
> > identified recurrence instance. The section is actually quite clear 
> > when it differentiates the 'recurring instance' and the initial VTODO 
> > component. 

It should be noted that there is no text regarding the latter case 
described ("specified using the "RECURRENCE-ID" property").  I suspect 
that the reason for this is the change of design of RECURRENCE-ID from 
delta to fixed midway thru iCalendar development.  The editors simply 
missed that line but they removed any text that would describe "the 
latter" case, probably its own paragraph that simply got removed.

Had we stayed with the delta RECURRENCE-ID model then the latter case 
above would be relevant since it would be the instances previous DTSTART 
value thus you could derive the new DUE value.  With the fixed 
RECURRENCE-ID model, you wind up sending the DUE value (or DURATION) so 
that both the recipient and the Organizer have the same view of the VTODO 
(coupled with the fact that the iTIP reschedule would be a full snapshot, 
it would also logically have a specific DUE (or DURATION) value in it for 
the recipient to use)..

> If so I disagree as it says to calculate the due date from the DTSTART 
> and DUE
> dates to get the offset and apply it to RECURRENCE-ID (which would have 
to
> be different or it would be pointless).

The text says NOTHING how to _apply_ RECURRENCE-ID to get the DUE value. 
It only says:

   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. 

If the RECURRENCE-ID were changing each reschedule then you could use it 
to calculate a new DUE value.  However as its been noted ad naseum here 
(and supported by the original authors), the RECURRENCE-ID value does not 
change.  As such, a reschedule needs to provide the DUE (or DURATION) 
value since the reschedule is a full snapshot of the Organziers copy (and 
not vulnerable to sequencing problems).

> > RFC 2245 - 4.6.6 Alarm Component
> >    In an alarm set to trigger on the "START" of an event or to-do, the
> >    "DTSTART" property MUST be present in the associated event or 
to-do. 
> 
> If DTSTART were the same as RECURRENCE-ID or not, that would be true
> as START is defined to be relative to the 'start' of the component, and 
> not DTSTART.

Huh??  Each instance has its own DTSTART value thats different from its 
peers.  Each instance has its own VALARMs who TRIGGER relative to that 
instances DTSTART value.  There is no concept of VALARMs being ALL 
relative to the set defintion (aka the 1st instance of the set).

> If DTSTART were not present then recurring or not, you can not use
> any time relative to the 'start' (or 'DTSTART').

I agree.  The same goes for for entries that have no DTEND / DUE / 
DURATION too.  In fact thats spelled on in 2445:

   In an alarm set to trigger on the "START" of an event or to-do, the
   "DTSTART" property MUST be present in the associated event or to-do.
   In an alarm in a "VEVENT" calendar component set to trigger on the
   "END" of the event, either the "DTEND" property MUST be present, or
   the "DTSTART" and "DURATION" properties MUST both be present.

> For a recurring instance the effective start of an instance
> is defined in 2445 to be the RECURRENCE-ID.

No, the effective start of the instance is the DTSTART value. 
RECURRENCE-ID is strictly used to identify the instance and is ONLY the 
same value (for sure) when the instance is first created.  (Thats the 
"original value" bit in Section 4.8.4.4) 

The reason "effective" is used is because you have to consider timezone 
shifts, etc when you roll out repeating grammars to determine each 
instances startting date/time.  If we just used RDATEs then no shifting 
factors would be involved and the phrase "effective" would not be 
necssary.

> The text says that "START" is relative to the "start" of a component,
> it does NOT say START is relative to 'DTSTART'.
> 
> And "END"  is defined to be relative to the "end" of a component,
> it does NOT say END is relative to 'DTEND' or 'DURATION'

I hope you are referring to the DTSTART / DTEND of a particular instance 
of a component and not the 1st instance (the one that is used to make 
copys at all the specified repeating dates that come after it).

If not, you would have ALL alarms for all instances trigger at the exact 
same time and NOT per instance and thats hardly the intent anyone would 
have.  Right?  (Talking about particular property [ie DTSTART] on a 
component [ie VEVENT] is somewhat problematic when the component is 
defined as a repeating one since its unclear which instance you are 
referring to.)

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