Subject: [Ietf-calsify] Interpretation of the UNTIL part of RRULEs in Timezones

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Wed Mar 21 09:29:53 2007

I'm hoping you can confirm my understanding of the timezone RRULE 
processing:

DTStart has to be interpreted as local time:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.6.5
      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.

Until has to be interpreted as Utc:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.3.10

      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 restated and refined further for timezones:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.6.5

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

Should RRULE have ByHour components, then I can only assume these follow 
DTSTART and therefore apply to local time, not UTC.  So this means to expand 
the recurring rule, we have to essentially use "floating time", as we can't 
really use localtime as that's what we are in the process of defining.  ie 
we use a fixed UTC offset (TZOFFSETFROM) to go from UTC to local time for 
the purposes of the expansion.

The first instance comes from DTSTART, yet the upper bound is in UTC which 
means presumably that we have to adjust the UNTIL date also using 
TZOFFSETFROM so that it is also in the same timesystem as our recurrence 
instances so that we can compare them.

So for example, consider this relatively arbitrary daylightc derived by an 
online tool (tziCal) from olson

BEGIN:DAYLIGHT
DTSTART:19180331T020000
RRULE:FREQ=YEARLY;UNTIL=19190330T060000Z;BYDAY=-1SU;BYMONTH=3
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT

First instance is
19180331T020000 = 19180331T070000Z
Last instance is
19190330T010000 = 19190330T060000Z

And therefore according to the standard, the TZ decl is wrong as 
19190330T010000 is not in the recurrence set and is therefore not the last 
instance generated by the recurrence pattern.  Unless of course UNTIL is 
meant to convert to UTC using OFFSETTO in which case it would be T020000 and 
the decl is right.  Were that to be the case I'd sure like to see it 
clarified in the standard.

This certainly seems overly complex with a lot of unnecessary switching 
between UTC and mysterious floating times.  I also find the below comment 
decidedly unhelpful.  Why can't it say how we are meant to use TZOFFSETFROM 
rather than just that we should?  I'd suggest alternative language, but I 
would first want to be sufficiently sure that I am understanding this 
correctly, and that I am not yet again discussing issues that aren't on the 
"blessed" list.

      *  The "DTSTART" and the "TZOFFSETFROM" properties MUST be used
         when generating the onset date-time values (instances) from the
         "RRULE".

I'd also like to remind you of my suggestions WRT to RRules in timezones. 
These would mean expanding RRules for timezones dont care about times only 
dates and much of these grey areas dissapear:
- Limit to yearly
- prohibit byhour, byminute, bysecond,

I would like to add to the list that for RRules we put DTStart and Until in 
the same timesytem, ie both in UTC or both in localtime.  In fact if UNTIL 
specified a DATE rather than a DATE-TIME that would be even clearer and less 
to process.

Nigel

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed Mar 21 18:14:15 2007

Hi Nigel,

--On March 21, 2007 5:28:51 PM +0000 Nigel Swinson 
<[email-masked]> wrote:

> 19190330T010000 is not in the recurrence set and is therefore not the
> last instance generated by the recurrence pattern.  Unless of course
> UNTIL is meant to convert to UTC using OFFSETTO in which case it would be
> T020000 and the decl is right.  Were that to be the case I'd sure like to
> see it clarified in the standard.

It seems at first glance the DAYLIGHT component is not valid as UNTIL is 
not the last instance. i.e. the tool doing the conversion got it wrong.

-- 
Cyrus Daboo