[Ietf-calsify] 2nd and higher instance busted across time zone changes.

[Jonathan Lennox]

On Saturday, April 9 2005, "Doug Royer" wrote to "ietf-calsify at osafoundation.org" saying:

> In CALSIFY I am proposing that we say that DURATION = DTEND - DTSTART
> as the way to process RDATE and any 2445 RRULE found. It ~looks~
> to me as if that is how most implementations did it.

That's certainly the simpler way to do it, and possibly the best-defined
way.

However, I don't think it satisfies the principle of least astonishment.  If
a work shift always goes from midnight to eight a.m., the usual cultural
convention is that you have a seven hour shift on the clocks-forward day, and
a nine hour shift on the clocks-backward day.

I think a more intuitive resolution rule is as follows:

1. If the RDATE or RRULE instance falls at a different time of day than
   DTSTART, DURATION = DTEND - DTSTART always.

2. However, if an RDATE or instance of an RRULE falls at the same time of
   day (in the relevant time zone, ignoring offset shifts) as DTSTART, then
   the end of the recurrance instance falls at the same time of day as
   DTEND, even if this would mean that the event has greater or lesser
   duration.

3. If the DTEND computed by rule 2 above doesn't exist (because it would
   fall during a clocks-forward period), or if it is ambiguous (because the
   time is repeated during a clocks-back period), fall back to rule 1.  For
   clocks-back, this should always have DTEND being one of the repeated
   times; for clocks-forward, the end time in the new offset should be
   equivalent to the "proper" end time in the old offset.  (Both of these
   conclusions assume sane DST rules, e.g. you don't have multiple
   transitions in a single 24-hour period.)

The only surprising behavior with this rule would be when you have a rule
whose base DTSTART-DTEND period spans an offset shift, *and* some RDATEs or
RRULE instances fall at different times of day than DTSTART.

This definition is more complicated, but I think it reflects human
expectations better.  The counter-argument for Calsify of "it's not how
existing clients do it" is a strong one, though.

Either way, these semantics needs to be made explicit in whatever becomes
the updated definition of recurring events.

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu