Subject: [Ietf-calsify] Fw: Discussion of UNTIL when used with STANDARD and DAYLIGHT sub-components

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 17 Mar 2008 13:06:16 -0000

Third attempt at sending:

----- Original Message ----- 
From: Nigel Swinson
To: [email-masked]
Sent: Friday, February 08, 2008 4:14 PM
Subject: Discussion of UNTIL when used with STANDARD and DAYLIGHT
sub-components

First point from a mail form 21st September that nobody seemed to receive:

> >> 3.3.10.  Recurrence Rule
> >>
> >>       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.  Furthermore, if the
> >>       "DTSTART" property is specified as a date with local time, then
> >>       the UNTIL rule part MUST also be specified as a date with local
> >>       time.  If the "DTSTART" property is specified as a date with
> >>       UTC time or a date with local time and time zone reference, then
> >>       the UNTIL rule part MUST be specified as a date with UTC time.
In
> >>       the case of the "STANDARD" and "DAYLIGHT" sub-components the
UNTIL
> >> -      rule part MUST always be specified as a date with UTC time.  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
> >> +      rule part MUST always be specified as a date with UTC time,
> >> with the
> >> +      "DTSTART" always represented as a date with local time.  If the
> >> UNTIL
> >> +      and COUNT rule parts are not
>>>          present, the "RRULE" is considered to repeat forever.
> >>
> >
> > Substantial.
>
> Nigel's addition is not substantial.  It is repeating what is
> already specified in section 4.6.5 "Time Zone Component" of
> RFC 2445, that is:
>
>     The mandatory "DTSTART" property gives the effective onset date and
>     local time for the time zone sub-component definition. "DTSTART" in
>     this usage MUST be specified as a local DATE-TIME value.
>
> I'm not convinced we should repeat this information.
>
> No change done.

The existing text has this:

      ...  In
      the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
      rule part MUST always be specified as a date with UTC time.  If
      specified as a DATE-TIME value, then it MUST be specified in a UTC
      time format. .......

One of my objectives was to get rid of the second sentence, as I don't think
it adds anything, and in the context of the whole paragraph it's confusing
to know what the second sentence is even refering to.  If this second
sentence is to stay could someone please explain what it adds?

My second objective was indeed to correlate more fully the relationship
between DTSTART and UNTIL as it says in 4.6.5.  The start of the paragraph
has described this relationship in detail for DTSTART and UNTIL under normal
circumstances, but then goes on to talk about the behaviour within the
STANDARD/DAYLIGHT components.  I think either it should leave all the
discussion of it's behaviour within STANDARD/DAYLIGHT to section 4.6.5, or
complete the discussion by saying, as I had suggested, that UNTIL is always
date with UTC time and DTSTART is always date with local time.

My third objective was to cleanup the language of the last sentence.

So please can we have either:

       time.  If the "DTSTART" property is specified as a date with
       UTC time or a date with local time and time zone reference, then
       the UNTIL rule part MUST be specified as a date with UTC time.  In
       the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
 -      rule part MUST always be specified as a date with UTC time.  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
 +      rule part MUST always be specified as a date with UTC time, with the
 +      "DTSTART" always represented as a date with local time.  If the
+       UNTIL and COUNT rule parts are not
       present, the "RRULE" is considered to repeat forever.

Or:

       time.  If the "DTSTART" property is specified as a date with
       UTC time or a date with local time and time zone reference, then
-       the UNTIL rule part MUST be specified as a date with UTC time.  In
-       the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
-       rule part MUST always be specified as a date with UTC time.  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
+       the UNTIL rule part MUST be specified as a date with UTC time.
+       If the UNTIL and COUNT rule parts are not
       present, the "RRULE" is considered to repeat forever.

Nigel
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify