Subject: [Ietf-calsify] DST discontinuities part 2: discontinuities for recurring event start times

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Nov 6 15:58:14 2006

Issue 2 has to do with how you handle the case when a recurrence's
start time falls within a discontinuity.

I suggest that by default, the "naive" behavior should be followed: i.e.,
events that would fall at non-existent times do not occur, and events that
fall at repeated times occur twice.  Calendar authors that want other
behaviors should use RDATE and EXDATE to get what they want.

(If existing clients consistently do something different, we should define
that behavior instead; this could use testing.)

The two relevant examples are, first, a forward jump in time:

   DTSTART;TZID=America/New_York:20060331T023000
   DURATION:PT1H
   RRULE:FREQ=DAILY;COUNT=4

In my suggested resolution, the event recurs at:

2006-03-31 02:30:00 EST
2006-04-01 02:30:00 EST
2006-04-03 02:30:00 EDT
2006-04-04 02:30:00 EDT

The second example, a backward jump in time:

   DTSTART;TZID=America/New_York:20061028T013000
   DURATION:PT1H
   RRULE:FREQ=DAILY;COUNT=4

In my suggested resolution, the event recurs at:

2006-10-28 01:30:00 EDT
2006-10-29 01:30:00 EDT
2006-10-29 01:30:00 EST
2006-10-30 01:30:00 EST

-- 
Jonathan Lennox
[email-masked]

---

From: lear at cisco.com (Eliot Lear)
Date: Thu Nov 16 07:24:53 2006

John,

> behaviors should use RDATE and EXDATE to get what they want.

It may be illustrative to note that Vixie cron with the -s flag does not 
behave in this way because it is not what one would want or expect 
intuitively, at least by his estimation.  His changes only involve 
events that occur minutely or hourly.

Eliot