Subject: [Ietf-calsify] Resolutions of issues 8, 68 and 69: DST discontinuities

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Thu Mar 1 09:54:31 2007

Following today's Jabber chat, Bernard asked me to follow up on the
resolutions of the DST discontinuity issues we discussed.

This is sort of a mixture of informal discussion and proposed text; sorry
about that.

For issue 8 (P1D vs. PT24H):

ISO 8601 defines D and W durations (and also larger ones that iCalendar
doesn't use) as being "nominal" durations, while the smaller periods are
"accurate" durations".  (See the jabber logs for the full quote from 8601).

To align with 8601 and remove ambiguity, then, we propose:
* D and W durations are nominal, i.e. refer to the same wall-clock time n
days or weeks later.
* H, M, and D durations are accurate, i.e. refer to an actual number of
elapsed hours, minutes, or seconds.
* We forbid DURATION values that mix nominal durations (W [already
forbidden] and D) with accurate durations (H, M, and S).

The third bullet point here is the potentially controversial one, and would
be an incompatible change with 2445.  Does anyone currently generate
DURATION values of the form "P1DT8H"?

For issue 68 (ambiguous or nonexistent DATE-TIME values):

Calendar generators MUST NOT generate DATE-TIME values that are non-existent
(occurring in a time zone's leap-forward period) or ambiguous (occurring
more than once, due to a time zone's leap-backward period) in the time zone
in which they occur, except in VTIMEZONE or EXDATE components.  If such
values appear in an iCalendar document, the meaning is undefined.  Calendar
generators SHOULD alert the user if such a time is requested, and SHOULD
instead represent the DATE-TIME values in a different time zone, or UTC,
where the instant is well-defined.

(This is "undefined" in the strict standardese sense, i.e. "demons can fly
out your nose."  A more likely undefined behavior would be something like
"java.util.GregorianCalendar.computeTime() throws an uncaught exception,
terminating your program.")

For issue 69 (discontinuities for recurring event start times):

If a time generated by an RRULE falls on an ambiguous or non-existent time,
the resulting event occurs exactly once (and thus counts as one recurrence
instance for the purposes of COUNT and BYSETPOS).  However, the actual time
at which the event occurs is unspecified.  [Note: do we need some guidance
bounding the range of valid times here, for the sake of UNTIL below?]

Calendar generators SHOULD alert the user in this case.  Once the user
provides a desired interpretation, calendar generators SHOULD provide EXDATE
entries matching the ambiguous or non-existent recurrence instances, with
corresponding RDATE entries in UTC or a non-ambiguous time zone indicating
the actual desired occurrence time of the recurrence instance.  (Note
however that this is not possible for perpetual recurrences, which might
have an unbounded number of ambiguous recurrence instances.)

If the last occurrence of a recurrence bounded with UNTIL falls at an
ambiguous or non-existent time, the UNTIL value (which MUST be in UTC)
SHOULD be specified to be after the range of ambiguous or non-existent
times, so the final occurrence definitely occurs no matter what time the
interpreter of the iCalendar document chooses for the event.

Comments?

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

---

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Thu Mar 1 10:12:53 2007

Hi Jonathan,

> DURATION values of the form "P1DT8H"?

Chandler doesn't currently serialize durations, but internally we store
durations and I've been trying to move things over to serializing
DURATION instead of DTEND.

I'm not following why we'd disallow "P1DT8H".  What's wrong with this
heuristic for interpreting such a value: Add the nominal time first,
then add the accurate time delta?

Sincerely,
Jeffrey

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Thu Mar 1 11:44:52 2007

Hi Jonathan,

--On March 1, 2007 12:27:50 PM -0500 Jonathan Lennox 
<[email-masked]> wrote:

> The third bullet point here is the potentially controversial one, and
> would be an incompatible change with 2445.  Does anyone currently generate

Yes, Mulberry will, for whatever its worth. In fact it explicitly allows 
users to set Durations for events using a UI that exposed fields for Days, 
Hours, Minutes and Seconds (or just Weeks). Note that I wrote the iCalendar 
library to manipulate dates as separate components for years, months, days, 
hours, minutes, seconds - i.e. handling "nominal" durations is easy.

I think Jeffrey's comment is right - there is nothing wrong with mixing 
nominal and accurate in this case.

-- 
Cyrus Daboo

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Thu Mar 1 11:44:54 2007

Moving forward a bit while I have it in mind, I think the resolutions of
issues 68 and 69 from today's Jabber can be generalized pretty easily to
issue 70 (ambiguous end times).

Given our resolution of issue 8, ambiguous event end times can only occur
because of nominal durations (D and W), not accurate durations (H, M, and
S).  Thus, the problematic cases are:

DTSTART;TZID=America/New_York:20070310PT023000
DURATION:P1D

and

DTSTART;TZID=America/New_York:20070309PT023000
DURATION:P1D
RRULE:FREQ=DAILY;COUNT=2

remembering that in the U.S.'s new DST rules, 2007-03-11 01:59:59 EST is
followed by 2007-03-11 03:00:00 EDT.

My inclination is to follow the same solution for DTSTART+nominal duration
as we followed for DATE-TIME.  I.e., an event end time from an explicit
DTSTART+nominal duration that hits a "bad" time is undefined, and MUST NOT
be generated (generalization of 68); an event end time from a recurrence
start+nominal duration that hits a "bad" time is unspecified, and the
recurrence instance SHOULD be overridden with an EXDATE (generalization of
69).

Does this seem reasonable?

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Thu Mar 1 11:47:23 2007

Following today's jabber discussion, I'd also suggest clarifing issue 27's
consensus, in the new terminology, to say that DTEND - DTSTART is always an
accurate duration, not a nominal duration.  Thus, issue 27's example 2

  DTSTART;TZID=America/Montreal:20070311T000000
  DTEND;TZID=America/Montreal:20070312T000000
  RRULE:FREQ=DAILY;COUNT=2

is exactly equivalent to

  DTSTART;TZID=America/Montreal:20070311T000000
  DURATION:PT23H
  RRULE:FREQ=DAILY;COUNT=2

because 2007-03-12 00:00:00 EDT is 23 elapsed hours after 2007-03-11
00:00:00 EST in America/Montreal.

I'm pretty sure this is what the consensus on issue 27 was, but I think this
makes things clearer and is easier to understand.

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Thu Mar 1 12:10:47 2007

> then add the accurate time delta?

So long as the rule is clearly defined as "add nominal duration first, then
accurate duration", that's okay.  Is this additional complexity actually
useful, though?

In particular, this might make my proposed resolution of issue 70 more
difficult to implement.  For a calendar generator, it's not sufficient to
say "alert the user if the end time of this event, calculated naively, would
be nonexistent or ambiguous".  Instead, it would have to ask "does the
process of calculating the nominal part of this event's duration hit a
non-existent or ambiguous time?" which is perhaps a more complex question to
answer.

That is to say, a calendar generator has to realize that not only is this a
problem:

(which would last from 2007-03-10 02:30:00 EST to *"2007-03-11 02:30:00")

but also this:

DURATION:P1DT8H

(which you might naively calculate as lasting from 2007-03-10 02:30:00 EST
to either 2007-03-11 10:30:00 EDT or 2007-03-11 11:30:00 EDT, and not
realize that something's wrong). 

-- 
Jonathan Lennox
[email-masked]