[Ietf-calsify] 2nd and higher instance busted across time zone
lennox at cs.columbia.edu
Sat Apr 9 20:14:35 PDT 2005
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
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
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.
lennox at cs dot columbia dot edu
More information about the Ietf-calsify