[Ietf-calsify] Issue 27: DURATION/DTEND ?

[Arnaud Quillaud]

> -----Message d'origine-----
> De : ietf-calsify-bounces at osafoundation.org
> [mailto:ietf-calsify-bounces at osafoundation.org] De la part de 
> Reinhold Kainhofer
> Envoyé : mardi 10 avril 2007 18:38
> À : ietf-calsify at osafoundation.org
> Objet : Re: [Ietf-calsify] Issue 27: DURATION/DTEND ?
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am Dienstag, 10. April 2007 schrieb Arnaud Quillaud:
> > With the new rule (use the "computed duration of the first
> instance"
> > for all instances), one can no longer create a recurring event that
> > *always* starts at 22:00 and always ends at 6:00 the next day.
> 
> That has never been possible anyway! It is not a new rule,
> but has always been 
> the case. 

OK. It is not a *new* rule. I should have said "With the proposed interpretation of recurring events duration". But other interpretations have always existed. For example, some of the most widely deployed calendar softwares interpret:

	DTSTART;TZID=America/Montreal:20070309T220000
	DTEND;TZID=America/Montreal:20070310T060000
	RRULE:FREQ=DAILY;COUNT=5;INTERVAL=1

as having 5 instances, all of which end at 06:00, even if there is a DST change on 20070311.

Having all instances end at 06:00 seems to me like a more natural interpretation from an end user perspective. In addition, the other behavior (1 instance ends at 07:00 on DST change) can always be generated by using DURATION: PT8H instead of DTEND.
 

> E.g. how would you determine the events for
>    DTSTART;TZID=America/Montreal:20070311T000000
>    DTEND;TZID=America/Montreal:20070312T000000
>    RRULE:FREQ=HOURLY;COUNT=5;INTERVAL=12
> if not by taking the duration of the initial event as the
> event for all 
> remaining occurrences?

Indeed, there is no other way. But in that case, the same set of instances can be generated by using DURATION:PT23H. 

If we come back to the end user need, there are some real life calendar objects (e.g. working shifts) that:
* are recurring,
* always start at the same time of day **and** end at the same time of day.
Other recurring objects are usually expressed using a duration (days, hours, minutes, seconds).

Translated into ical this means that the use of DTSTART+DTEND (with VALUE=DATETIME) in recurring event should be reserved to express the first type of objects. All other recurring objects should use DTSTART+DURATION or DTSTART+DTEND (with VALUE=DATE).

In other words recurring events using DTSTART+DTEND (with VALUE=DATETIME):
1) should not contain HOURLY/MINUTELY/SECONDLY, or BYHOUR/BYMINUTE/BYSECOND element in their RRULE definition.
2)should generate valid end time for all instances (RDATE can be used to specify problematic instances).
3) should have all RDATE specified with a value type of PERIOD.

Each instance end is calculated by:
1) adding to the instance start the number of days betweeen DTEND and DTSTART date part,
2) setting the time part to the same time of day as the original DTEND.

Recurring events using DTSTART+DTEND (with VALUE=DATE) are equivalent to recurring events using DTSTART + DURATION where the duration is expressed in number of days.

I think most existing recurring events using DTSTART+DTEND more or less already comply with the rules above (I have yet to see a cal client that would let you create HOURLY/MINUTELY/SECONDLY).Nevertheless we may want to provide a fallback mechanism (e.g. use the duration of the first instance).

Arnaud Q
> 
> Cheers,
> Reinhold
> 
> - --
> - ------------------------------------------------------------------
> Reinhold Kainhofer, Vienna University of Technology, Austria
> email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
>  * Financial and Actuarial Mathematics, TU Wien, 
> http://www.fam.tuwien.ac.at/
>  * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
>  * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFGG71lTqjEwhXvPN0RAkoEAKC2r0P4jyao8zxxyrK8x6CZrEIP3gCgnwPQ
> nMQ/zCCNITiIgXchZOPTyXQ=
> =s1PR
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org 
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>