[Ietf-calsify] floating RRULEs and UNTIL values

[Bernard Desruisseaux]

Here's how the story goes:

- The requirement to have UNTIL specified in UTC was specified
   in RFC 2445:

   > If specified as a date-time value, then it MUST be specified
   > in an UTC time format.

- At the 66th IETF Meeting in Montreal (July 2006) we've agreed
   to clarify that the value of the UNTIL rule part MUST have the
   same value type as the "DTSTART" property (Issue 23). As you'll
   see in the minutes the issue you are bringing up was briefly
   discussed:

   http://www3.ietf.org/proceedings/06jul/minutes/calsify.txt

   > 4 4.3.10 on UNTIL rule.  Should clarify whether UNTIL can use a DATE
   > value type.
   >
   > AI: Room showing agreement that the draft should state that
   > the UNTIL value type MUST match DTSTART value type.
   >
   > Another issue with whether UNTIL DATE-TIME should be allowed to float
   > or not (currently UTC a MUST). Might still be a problem if DTSTART is
   > a local time; however, JeffMc points out later that DTSTART is not
   > allowed to float currently, so should not be an issue.

- At the 67th IETF meeting in San Diego (November 2006) we've agreed
   to clarify that all forms of DATE-TIME were allowed for DTSTART and
   DTEND/DUE in recurring components (i.e., also DATE WITH UTC TIME).
   (Issue 43). Except for VTIMEZONE sub-components where DTSTART is
   REQUIRED to be in UTC:

   http://tools.ietf.org/wg/calsify/minutes?item=minutes67.html

   You can also check:

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-September/001172.html

- Also in November 2006, Tim and Cyrus pointed out that we must allow
   floating time recurring events.  See thread:

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001353.html

Given what was previously agreed for issue 23 and issue 43 I believe
a change to the specification for the UNTIL rule part is advisable.

In the case of VTIMEZONE sub-components the DTSTART is specified as a
date with local time but is not really floating since "TZOFFSETFROM"
always gives you its UTC offset. As such it does make sense to have
a "floating" DTSTART and an UNTIL rule part with a UTC time in a
VTIMEZONE sub-component.

In the case of VEVENT components if the DTSTART is specified as a
date with local time and the UNTIL rule part is specified as a date
with UTC time then people in different time zones could end up with
a different number of recurrence instances.  Not good.

Given all of the above, here's what I propose:

  The UNTIL rule part MUST be specified as a date with UTC time,
  unless DTSTART is specified as a date with local time, except
  in VTIMEZONE sub-components where the UNTIL rule part MUST
  always be specified as a date with UTC time.

Thanks,
Bernard

Jeffrey Harris wrote:
> There are a few places in draft 6 that say something like this:
> 
>       The UNTIL rule part defines a DATE or DATE-TIME value which bounds
>       the recurrence rule in an inclusive manner.  If the value
>       specified by UNTIL is synchronized with the specified recurrence,
>       this DATE or DATE-TIME becomes the last instance of the
>       recurrence.  The value of the UNTIL rule part MUST have the same
>       value type as the "DTSTART" property.  If specified as a DATE-TIME
>       value, then it MUST be specified in a UTC time format.  If not
>       present, and the COUNT rule part is also not present, the "RRULE"
>       is considered to repeat forever.
> 
> and later,
> 
>       *  If observance is known to have an effective end date, the
>          "UNTIL" recurrence rule parameter MUST be used to specify the
>          last valid onset of this observance (i.e., the UNTIL date-time
>          will be equal to the last instance generated by the recurrence
>          pattern).  It MUST be specified in UTC time.
> 
> What about recurring floating events?  Seems like we're either
> forbidding floating events from using UNTIL, or we're saying even
> floating recurring events need to have UNTIL values in UTC, which I
> think is a bad idea.
> 
> How about removing the latter paragraph's insistence on UTC, since it
> doesn't apply to DATE valued recurring events or floating events, and
> changing the first to:
> 
>       The UNTIL rule part defines a DATE or DATE-TIME value which bounds
>       the recurrence rule in an inclusive manner.  If the value
>       specified by UNTIL is synchronized with the specified recurrence,
>       this DATE or DATE-TIME becomes the last instance of the
>       recurrence.  The value of the UNTIL rule part MUST have the same
>       value type as the "DTSTART" property.  If DTSTART is specified as
>       a DATE-TIME value with a timezone, then UNTIL MUST be specified in
>       a UTC time format.  If DTSTART is specified as a floating
>       DATE-TIME, UNTIL MUST specified as a floating DATE-TIME.  If not
>       present, and the COUNT rule part is also not present, the "RRULE"
>       is considered to repeat forever.
> 
> Sincerely,
> Jeffrey
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify