Re: DTSTART for recurrence instances

Olivier Gutknecht wrote:

> On 2 déc. 03, at 03:14, Doug Royer wrote:
>
>> Craig Johnson wrote:
>>
>>> Unless I have misunderstood, this seems contrary to common
>>> practice.  Some clarification regarding DTSTART value for
>>> recurrence instances would be helpful.
>>>  Suppose we have a recurring event for every Monday in January:
>>>  BEGIN:VEVENT
>>> SUMMARY:Every Monday in January
>>> DTSTART:20040105T100000Z
>>> DTEND:20040105T110000Z
>>> UID:A-Unique-ID
>>> RRULE:FREQ=WEEKLY;UNTIL=20040131T170000Z;
>>>  INTERVAL=1;BYDAY=MO;WKST=SU
>>> ...
>>> END:VEVENT
>>>  Now suppose we SEARCH for that event with Expand:TRUE:
>>>  BEGIN:VQUERY
>>> EXPAND:TRUE
>>> QUERY: SELECT * from VEVENT
>>>   WHERE UID = 'A-Unique-ID'
>>> END:VQUERY
>>>  What will be returned in the query?  Will the DTSTART
>>> (and DTEND) of each recurrence instance be the same as
>>> the 'master' (as in column 1 below)?
>>
>>
>> Yes. And each object returned will have a RECURRENCE-ID property
>> added with its value set to the effective start time of that instance 
>> of the component.
>> All objects returned will have the same DTSTART /  [ DTEND | DURATION ]
>
>
> 2445 and 2446 mention RECURRENCE-ID as a way to actually identify 
> component instance more than for actual date for the event. For 
> example, in RFC 2445, sect 4.2.7:
>     'Component instances are identified by the combination of "UID", 
> "RECURRENCE-ID", and "SEQUENCE"
>
> Or: RFC 2445, sect 4.8.4.4
>    The full range of calendar components specified by a
>    recurrence set is referenced by referring to just the "UID" property
>    value corresponding to the calendar component. The "RECURRENCE-ID"
>    property allows the reference to an individual instance within the
>    recurrence set.
>
> RFC 2446, sect 2.1.5
>     To reference an instance of a recurring component, the primary key 
> is composed of the "UID" and
>     the "RECURRENCE-ID" properties.
>
> There is also a note in 2445 4.8.4.4 about DATE value type that 
> actually tells something about DTSTART semantics in a RECURRENCE-ID 
> based component:
>
>  If the value of the "DTSTART" property is a DATE type value, then the
>    value MUST be the calendar date for the recurrence instance.
>
> The definition here is for the -recurrence instance- and is a MUST. 


Yes and as the section and subject of that text is  'Recurrence ID', as in :

    If the value of the "DTSTART" property is a DATE type value, then the
     value [of RECURRENCE-ID] MUST be the calendar date for the 
recurrence instance
    

>> IN 2445 (EXDATE) (a similar section for EXRULE also exists):
>>
>>   The "EXDATE" property can be used to exclude the value specified in
>>   "DTSTART". However, in such cases the original "DTSTART" date MUST
>>   still be maintained by the calendaring and scheduling system because
>>   the original "DTSTART" value has inherent usage dependencies by other
>>   properties such as the "RECURRENCE-ID".
>
>
> This is coherent in that case: making an exception on original DTSTART 
> with an EXDATE must not change the other, unrelated component 
> instances in the recurrence, as the RECURRENCE-ID is using the date 
> where an occurrence should happen in the recurrence. The recurrence 
> definition must not change for this to be possible, this include the 
> RRULE of course, and the original DTSTART.  This has been corroborated 
> by Frank Dawson and Derik Stenerson recently:
>
>     " a) the value for RECURRENCE-ID was agreed to be the date/time 
>  value of the original recurrence instance. This value remains 
> unchanged for as  long as the base recurrence set (or pattern) exists. 
> A rescheduling of an  individual recurrence instance did not cause 
> creation of new base recurrence  set, but only moved the start/end of 
> the specified recurrence instance.   


>
> RFC 2445 in 4.8.5.1 also mentions:
>      The "DTSTART" property defines the first instance in the 
> recurrence set.
> But note that this is in the context of a component defining the 
> recurrence (RRULE, EXDATE, RDATE, EXDATE, ...), not in the context of 
> a RECURRENCE-ID identified component instance. Actually, DTSTART 
> definition (4.8.4.2) only refer to the VEVENT component:
>     Description: Within the "VEVENT" calendar component, this property
>    defines the start date and time for the event.
>
> So it seems somewhat unrelated to the DTSTART issue within a 
> RECURRENCE-ID identified component from Craig's example. 

My point was that it can not be both ways. It has to change or it never 
changes.

>> The only time the DTSTART is not the same as the master is when
>> specifying a change to a single instance as described in iTIP 3.7.1
>> and 4.4.2 . Then the master is not altered, just the specific object
>> declaring the change details.
>
>
> I think the issue comes from ambiguities like:
>
> RFC 2445 - 4.8.2.3 Date/Time Due
>    Description: The value MUST be a date/time equal to or after the 
> DTSTART value, if specified. 

I do no know why that would be ambiguous, for the 1st or Nth entry that 
would
be true no matter if DTSTART was changed or not.

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

So you are saying that the DUE date must change in each expanded instance
of a recurring VTODO?

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

 this-instance-due = ( DUE - DTSTART) + RECURRENCE-ID

 Where DUE must be >= DTSTART as defined in 2445 in your quote above.

> And also:
>
> 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.

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

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

So for an expanded component (With RECURRENCE-ID):

    component-start-time = RECURRENCE-ID
 
    alarm-start-time = component-start-time + 'START'

    component-end-time =   RECURRENCE-ID + DURATION

      -or-
 
     component-end-time =  RECURRENCE-ID + ( DTEND - DTSTART)

     alarm-end-time = component-end-time + 'END'

> RFC 2445 - 4.8.6.3 Trigger
>     If the trigger is set relative to START, then the "DTSTART" property
>    MUST be present in the associated "VEVENT" or "VTODO" calendar
>    component.
>
> In all these cases, the property is defined relative to the DTSTART 
> (or DTEND) of the associated component. If we assume that the DTSTART 
> is the DTSTART of the original event, how can we express an iTIP ADD 
> ("especially useful if there are instance-specific properties to be 
> preserved in a recurring "VEVENT"" -  idem for VTODO) or COUNTER and 
> referring to actual DTSTART instance in that case and to global 
> DTSTART in another case ? 

No.

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'

See "4.2.14 Alarm Trigger Relationship"

>>> Or will DTSTART and DTEND have the 'effective' value for the 
>>> recurrence instance
>>> (as in column 2 below)?
>>
>> No. Why would there need to be a new property (RECURRENCE-ID)?
>> It could be done with a boolean (this is a single instance) to DTSTART
>> if that were true.
>
>
> Why introducing a new parameter if the existing model is sufficient ? 

I agree.

I am not proposing  new parameter. I am saying that defining DTSTART to
be the same as RECURRENCE-ID in an expanded instance is pointless
and the fact that RECURRENCE-ID exists is an argument for that fact it
needs to be different (when instance > 1st). Else why was it invented when a
boolean parameter would have worked?

>>> The expected result, intuitively and instinctively, is Column 2.
>>> The prior discussion thread implied that Column 1 is correct
>>> (along with some discussion explaining that this is why DTSTART
>>> is not always suitable for use in QUERYs, whereas RECURRENCE-ID
>>> is more suitable).
>>
>>
>> DTSTART is a fixed value for any specific revision of a UID.
>
>
> I can't see anything in 2445/2446 that explicitly states that (see 
> comments above about recurrence instances). 

See "4.8.7.4 Sequence Number", if DTSTART changes, the SEQUENCE MUST change.
Thus the specific revisions of the UID is not the same.

I used the words 'specific revision'  to mean 'pattern' as you quoted 
from Derik/Frank above.

So restated:

    DTSTART is a fixed value for any specific pattern  of a UID.
    Expanding the instances does not alter the DTSTART.

>> RECURRENCE-ID is calculated only when the object is expanded.
>
>
> I agree with that.
> However (DUE case above), if in the query result the returned DTSTART 
> is the original DTSTART, I assume that means that a DUE property will 
> also be the original component DUE value ? If find that worrying for 
> two reasons: 

Yes that is what I mean.

>    - EXPAND=TRUE is convenient for CUA that don't want or can't handle 
> the complete recurrence model (PDA or cell phones were cited in 
> earlier discussions). That means that the query results will not be 
> immediately usable. I'm also worried with the case of a original event 
> having an alarm and a specific instance having a  different alarm (a 
> case likely to be related to the ALARMID/SEQUENCE discussion).
>    - Semantics of the returned VEVENT/VTODO recurrence instances seem 
> to be debatable, because of the parts of RFC 2445  that mentions 
> recurrence instances as 'self sufficient' components (see above, 
> 4.8.4.1, 4.8.4.4). 

Doing date math is really simple even in a cell phone.

>>>  This is a fundamental issue that impacts interoperability. I'd like 
>>> to hear others view on this issue:
>>> What is the value of DTSTART for recurrence instances?
>>>   - DTSTART is the same as the 'master'.
>>>   - DTSTART is the 'effective' value for the instance.
>>
>
> I admit I also understand it as the effective value for the instance 
> component, instance which is identified through 
> UID/RECURRENCE-ID/SEQUENCE properties.
>
> Ol.


-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email protected]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards