Subject: [Fwd: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule: Duration of members of the,generated recurrence set]

From: cyrus at daboo.name (Cyrus Daboo)
Date: Tue Jan 16 08:42:30 2007

Hi Bernard,
Late reply on this.

> -------- Original Message --------
> Subject: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule:
> Duration of members of the,generated recurrence set
> Date: Thu, 19 Oct 2006 13:51:12 -0400
> From: Bernard Desruisseaux <[email-masked]>
> To: Calsify WG <[email-masked]>
>
> In section 4.8.5.4 Recurrence Rule it says:
>
>> Any duration associated with the iCalendar object applies to all
>> members of the generated recurrence set.
>
> I believe we need to clarify what is meant by "duration" here.
>
> Example 1:
>
>    DTSTART;TZID=America/Montreal:20070311T000000
>    DURATION:P1D
>    RRULE:FREQ=DAILY;COUNT=2
>
>    The first instance start at midnight on March 11th, 2007 and has
>    a duration of 1 day. Given that on that day there is a shift from
>    standard time to daylight saving time, this instance will actually
>    last 23 hours.
>
>    Should the duration of the recurrence instance that will occur on
>    March 12th, 2007 be the "computed duration of the first instance",
>    that is, 23 hours, or the "specified duration of the first instance",
>    that is, 1 day?
>
>    In my opinion, the duration of the recurrence instance on March 12th,
>    2006 should be 1 day (24 hours).

I agree.

> Example 2:
>
>    DTSTART;TZID=America/Montreal:20070311T000000
>    DTEND;TZID=America/Montreal:20070312T000000
>    RRULE:FREQ=DAILY;COUNT=2
>
>    The first instance start at midnight on March 11th, 2007 and is
>    specified to end at midnight on March 12th, 2007. Given that on
>    that day there is shift from standard time to daylight saving time,
>    this instance will actually last 23 hours.
>
>    I believe the duration of the recurrence instance on March 12th,
>    2006 should be the "computed duration of the first instance",
>    that is, 23 hours.

I agree.

> All that being said:
>
>    - I doubt that all (most?) iCalendar application will interpret
>      P1D as 23 hours or 25 hours when a time zone shift occurs.

I'm not so sure about that. It really depends on how date arithmetic has 
been implemented. In the library I wrote a while ago I kept the data 
components separate, so that doing +P1D actually meant incrementing the day 
value rather than adding a certain number of hours. More to the point is 
whether an implementation can spot that DTEND - DTSTART is actually 23 or 
25 hours during the dst shift. Again, the implementation I did would 
convert the separate date-time components into a "seconds" value and then 
subtract those, so that ought to get the correct 23/25 hour value.

Bottom line is someone should test the various libraries and see what 
happens! Libraries ought to include something like this as part of their 
unit tests.

>    - There are known iCalendar applications that don't even support
>      the DURATION property today!

What do you mean by "does not support"? Surely no one ignores it? I know 
there are some that never generate it (turning a component with 
DTSTART/DURATION into one with DTSTART/DTEND), but no one can ignore it and 
claim to support iCalendar.

-- 
Cyrus Daboo

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Tue Jan 16 10:39:25 2007

Cyrus Daboo wrote:

> DTSTART/DURATION into one with DTSTART/DTEND), but no one can ignore it 
> and claim to support iCalendar.

Microsoft Outlook 2000 ignores the DURATION property on import.
Perhaps that's been fixed in more recent versions of this product.

Cheers,
Bernard