Re: DTSTART for recurrence instances

[email protected]
Newsgroups gmane.ietf.calendar
Message-ID <OF7A8CB86F.D2105409-ON85256DF3.0069C643-85256DF3.006BBAFB@notesdev.ibm.com>
Craig wrote on 12/01/2003 08:07:59 PM:
> 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? 

Per the CAP 12-e text, ALL instances will be returned and as individual 
VEVENTs.  So the returned data should look something like:

BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040105T100000Z
DTEND:20040105T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040105T100000Z
...
END:VEVENT
BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040112T100000Z
DTEND:20040112T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040112T100000Z
...
END:VEVENT
BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040119T100000Z
DTEND:20040119T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040119T100000Z
...
END:VEVENT
BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040126T100000Z
DTEND:20040126T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040126T100000Z
...
END:VEVENT

>                                             Will the DTSTART 
> (and DTEND) of each recurrence instance be the same as 
> the 'master' (as in column 1 below)? 

No.  (Please be careful using 'master' as it introduces a new term w/o 
defining it.  I take it to mean the initial instance defined by your 
original VEVENT (sans repeating and exclusion grammar or RDATE / EXDATEs) 
but I could be slightly wrong.)

>                                       Or will DTSTART and 
> DTEND have the 'effective' value for the recurrence instance 
> (as in column 2 below)? 

Yes

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

I havent been able to keep on WG threads lately so I didnt see that. 

The interpretation depends on how you read the property defintions in 
2445.  From my catchup attempts on this thread (bottom up) it appears as 
if some grok the difference between instance identifier (UID and 
RECURRENCE-ID) and instance starting time (DTSTART) and some may not.   By 
correctly using each property as its defined,  I dont see how one would 
say Column 1 (omitted) is the correct answer but Ill go back and see if I 
missed something.

Essentially, the CUA needs to be smart about when it uses EXPAND:TRUE in a 
VQUERY.  It depends on what the CUA is attempting to do.

If you want to find a particular instance of a component (ie: 
UID:A-Unique-ID) then you would include RECURRENCE-ID to find it no matter 
where in time it exists and not use EXPAND (or use EXPAND:FALSE). 

If you want to find all instances of a component (ie: UID:A-Unique-ID) 
then you would omit any RECURRENCE-ID and use EXPAND:TRUE.

If you want to find any entires during a particular time range, say the 
work week starting 5-Jan-2004, (even those NOT with UDI:A-Unique-ID) you 
would omit any UID or RECURRENCE-ID and not use EXPAND (or use 
EXPAND:FALSE).

Its somewhat problematic if you do the latter AND include EXPAND:TRUE as 
the results returned would violate the WHERE constraints of the query.

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.