[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DTSTART for recurrence instances
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:
'<x-tad-bigger>Component instances are identified by the combination of "UID", "RECURRENCE-ID", and "SEQUENCE"</x-tad-bigger>
Or: RFC 2445, sect 4.8.4.4
<x-tad-bigger> 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.</x-tad-bigger>
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:
<x-tad-bigger> If the value of the "DTSTART" property is a DATE type value, then the
value MUST be the calendar date for the recurrence instance.
</x-tad-bigger>
The definition here is for the -recurrence instance- and is a MUST.
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. "
<x-tad-bigger>RFC 2445 in 4.8.5.1 also mentions:
The "DTSTART" property defines the first instance in the recurrence set. </x-tad-bigger>
But note that this is in the context of a component definining 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:
<x-tad-bigger>Description: Within the "VEVENT" calendar component, this property
defines the start date and time for the event. </x-tad-bigger>
So it seems somewhat unrelated to the DTSTART issue within a RECURRENCE-ID identified component from Craig's example.
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 specifc object
declaring the change details.
I think the issue comes from ambiguities like:
<x-tad-bigger>
RFC 2445 - 4.8.2.3 Date/Time Due</x-tad-bigger>
<x-tad-bigger> Description: The value MUST be a date/time equal to or after the DTSTART value, if specified.</x-tad-bigger>
<x-tad-bigger>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.
</x-tad-bigger>
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.
And also:
<x-tad-bigger>
RFC 2245 - 4.6.6 Alarm Component </x-tad-bigger>
<x-tad-bigger> 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.
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. </x-tad-bigger>
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 ("<x-tad-bigger>especially useful if there are instance-specific properties to be preserved in a recurring "VEVENT""</x-tad-bigger> - idem for VTODO) or COUNTER and referring to actual DTSTART instance in that case and to global DTSTART in another case ?
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 ?
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.
RECURRENCE-ID is calculated only when the object is expanded.
I agree with that.
However (DUE case above), if 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
- 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 conflicting with many parts of the RFC 2445 texts that mentions recurrence instances as 'self sufficient' components (see above, 4.8.4.1, 4.8.4.4).
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 also understand it as the effective value for the instance, instance which is identified through UID/RECURRENCE-ID/SEQUENCE properties.
Ol.