Subject: Duration: Does 1 day == 24 hours?

From: Eric Busboom <[email-masked]>
Date: Tue, 27 Mar 2001 15:22:02 -0800 (PST)

One of the Reefknot developers noticed that iCalendar is ambiguous
regarding how DURATION interacts with daylight savings time changes. In
particular, if you have an event with an end time that is specified as a
duration of 1 day, and the event crosses a daylight savings time change,
when does the event end?

Does it end 24 hours after the start time or 23 or 25 hours after the
start time?

I'd suspect that the right things to do is to define 1 day to mean "at the
same time tomorrow" or something like that. 

So, how about this as an addition to 4.3.6 Duration:

--------------------------------------------------------------------------------

For the purpose of calculating an end time based on a start time and a
duration, a day (dur-day) MUST be interpreted as the period spanning
between the same times on sucessive days, not as a period of 24 hours. So,
An event of 1 day duration that starts at 10:00 will end the following day
at 10:00, regardless of any intervening shifts between Standard Time and
Daylight Savings Time.

Similarly, a week ( dur-week) MUST be interpreted as a period of seven
days, not as 168 hours.  

--------------------------------------------------------------------------

So, if you really want an event to run 24 hours, use "PT24H" and if you
want it to end at the same time tomorrow, use "P1D"

eric.

---

From: John Stracke <[email-masked]>
Date: Wed, 28 Mar 2001 12:54:30 -0500

[email-masked] wrote:

> I disagree. The duration value type is setup to work either in precise time
> components (hours, minutes, seconds, partial seconds) or less precise
> components (year, month, week and day form).

Correction: DURATION does not support year and month components.  Week and Day
are just as precisely defined as Second; both can be defined as a precise
number of seconds.  See 2445/4.3.6:

     dur-value  = (["+"] / "-") "P" (dur-date / dur-time / dur-week)

     dur-date   = dur-day [dur-time]
     dur-time   = "T" (dur-hour / dur-minute / dur-second)
     dur-week   = 1*DIGIT "W"
     dur-hour   = 1*DIGIT "H" [dur-minute]
     dur-minute = 1*DIGIT "M" [dur-second]
     dur-second = 1*DIGIT "S"
     dur-day    = 1*DIGIT "D"

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |Just because we are out to get you does not mean|
[email-masked]|you are not paranoid.                           |
\=================================================================/

---

From: [email-masked]
Date: Wed, 28 Mar 2001 12:17:33 -0600

> At 11:48 2001-03-28 -0600, you wrote:
> >or (as we have been discussing)
> >
> >DTSTART;VALUE=DATE:20010328
> >DURATION:P1D
> 

More precise. Yes.

> Although now that dates alone are being discussed,
> how would you interpret this- would it be considered
> invalid?:
> 
> DTSTART;VALUE=DATE:20010328
> DURATION:PT11H
> 

Doesn't look very well-formed to me. I would judge this as one of those
anomalies and interpret as it would be if just the DTSTART was specified
(for iTIP/iMIP) but would flag as bad values if a CAP like access method was
used.

---

From: [email-masked]
Date: Wed, 28 Mar 2001 13:17:17 -0600

> >I disagree. As evidence, how would you interpret a 
> DURATION:P1M? Is it 30
> >day*24 hours? Or is it 28, 29 or 31? And what do you do for the other
> >calendar specific forms of DURATION values?
> 
> Nothing above a week is mentioned in RFC2445 4.3.6.

I spoke too early in reply to John. Check again. It does indeed include both
D, for day and W, for week duration.

---

From: [email-masked]
Date: Wed, 28 Mar 2001 14:57:03 -0600

> > I disagree. As evidence, how would you interpret a DURATION:P1M?
> 
> I just misspoke.  P1M means "one minute".
> 

PT1M would mean one minute. P1M would mean one month. But as you pointed out
that is nolonger allowed in the final iCalendar version. Just W and D for
calendar scale duration.

You were right to correct me.

---

From: [email-masked]
Date: Fri, 30 Mar 2001 16:46:15 -0600

> >I am struggling to see why duration is even required.  Why 
> have two ways to
> >define an events end datetime (start + dur or end)?  As far 
> as I can tell an
> >event's bounds can be defined by only the start time and an 
> end time (not
> >thinking about repeats here).  The inclusion of duration 
> seems to just
> >confuse the matter.
> 
> I agree. Apart from some obscure subtleties to do with
> Daylight/Standard Time changes, the same information can
> be expressed using either DTEND or DURATION. Why do we need
> both?
>

Agree that immediate uses can get by with just DTSTART and DTEND. However,
if that is all we ever have then you make it harder to specify an event or
to-do in terms of a relative period of time. This capability can be
important if you support applications that allow grouping of related events
or to-dos. With support for DURATION you can keep track of the relative
relationship of the periods for each event or to-do and make it easier to
adjust the duration of one of the group and keep the relative timing for the
others. 

An example used in the original discussion was support for interviews. Bob
is being interviewed by Alan, Mark and John. Each are scheduled to take one
hour. The interview process is originally set to begin at 08.30. Now Alan
decides he needs less time. The other events should slide down to start at
the corresponding earlier time, but keep their existing duration.

Granted, that duration can be calculated without DURATION, but it was
thought to be easier with this feature.

At least that is what I remembered from the discussions. Not sure if anyone
can find this discussion on the mailing list archive. I haven't checked.

-- Frank