Subject: DURATION vs DTEND

From: Dan Winship <[email-masked]>
Date: 02 Apr 2003 12:15:33 -0500

>From cap-10 6.1.1.10:

   As "DTEND" value is the first time that is excluded from a components
   time range, any "DURATION" value supplied by the "QUERY" property
   value that is exactly one second less than the "DTEND" property value
   MUST match the QUERY.  And if the "DURATION" property value ends
   exactly at the computed DTEND it MUST NOT match.

etc. That's wrong, right? DTSTART + DURATION == DTEND, not DTEND - 1

-- Dan

---

From: John Stracke <[email-masked]>
Date: Wed, 02 Apr 2003 12:48:15 -0500

>etc. That's wrong, right? DTSTART + DURATION == DTEND, not DTEND - 1
No, the text looks right.  That first clause ("...first time that is 
excluded...") says we're dealing with a half-open interval.

-- 
/============================================================\
|John Stracke      [email-masked]                     |
|Principal Engineer|http://www.centive.com                   |
|Centive           |My opinions are my own.                  |
|============================================================|
|"God does not play games with His loyal servants." "Whoo-ee,|
|where have you *been*?" --_Good Omens_                      |
\============================================================/

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 11:14:37 -0700

I think it is correct.

Given:
		DTSTART	1pm
		DTEND:  2pm

Equals:

		DTSTART: 1pm
		DURATION: 59 minutes, 59 seconds.

IF you use:

		DTSTART: 1pm
		DURATION: 60 minutes.

Then that would equal:

		DTSTART: 1pm
		DTEND: 2pm + 1 second.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: John Stracke <[email-masked]>
Date: Wed, 02 Apr 2003 13:36:56 -0500

>         DURATION: 59 minutes, 59 seconds. 

This does not make sense; you're saying that PERIOD(DTSTART, DTEND) is 
the half-open interval [DTSTART, DTEND), but PERIOD(DTSTART, DURATION) 
is the closed interval [DTSTART,DTSTART+DURATION].

I would say that PERIOD(1PM,2PM)==PERIOD(1PM, 1hr), but that 2PM is not 
contained in PERIOD(1PM,2PM)--i.e., that PERIOD(1PM,2PM)==[1PM,2PM).

---

From: Dan Winship <[email-masked]>
Date: 02 Apr 2003 14:15:21 -0500

> excluded...") says we're dealing with a half-open interval.

Yes, exactly.

How many integers are there in the half-open interval [0,1)? One.
So how many seconds are there in the half-open interval
[12:00:00,12:00:01)? I'd say 1 again, but according to the cap spec's
math, an event that starts at 12:00:00 and ends at 12:00:01 has a
duration of 0 seconds.

-- Dan

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 12:35:02 -0700

I do not understand what you mean by 'half open'.

There were discussions on this list about overlapping that
one second. Given two OPAQUE VEVENTS with:

		DTSTART:1pm
		DTEND:2pm

	and

		DTSTART:2pm
		DTEND:3pm

The 2nd one can not be booked if the 1st one is OPAQUE
as the 1st DTEND includes the first second of the 2nd DTSTART.
So we concluded that DTEND was the 1st second after the time
ended. Making the DURATION 59 minutes, 59 seconds.

I think this was even prior to CAP (but maybe not).

--

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 2 Apr 2003 15:04:47 -0500

This doesn't make any sense. DTEND is the non-inclusive time.

DTSTART 1pm,DURATION 0s
equals 
DTSTART 1pm,DTEND 1pm

DTEND = DTSTART + DURATION

Larry

   Date: Wed, 02 Apr 2003 11:14:37 -0700
   From: Doug Royer <[email-masked]>

   Given:
		   DTSTART	1pm
		   DTEND:  2pm

   Equals:

		   DTSTART: 1pm

   IF you use:

		   DTSTART: 1pm
		   DURATION: 60 minutes.

   Then that would equal:

		   DTSTART: 1pm
		   DTEND: 2pm + 1 second.

---

From: John Stracke <[email-masked]>
Date: Wed, 02 Apr 2003 15:26:38 -0500

> I do not understand what you mean by 'half open'. 

Ah.  Definitions:

(a,b) is the set of numbers x such that a<x and x<b.
[a,b] is the set of numbers x such that a<=x and x<=b.
[a,b) is the set of numbers x such that a<=x and x<b.
(a,b] is the set of numbers x such that a<x and x<=b.

(a,b) is an open interval; [a,b] is a closed interval; [a,b) and (a,b] 
are half-open intervals.

Standard mathematical terms.

> ended.

This is not a good way of approaching the problem; it's highly prone to 
off-by-one errors.  Plus, it doesn't leave room for expanding to 
subsecond resolution, should that ever be useful.  Half-open intervals 
are the Right Thing: the DTEND is not included in the interval, so there 
is no overlap between [a,b) and [b,c).

For a slightly more pragmatic approach: by your definition, if a user 
says "my opaque event starts at 1:00, and lasts for 1 hour", do you want 
to explain to them why they can't schedule another opaque event at 2:00?

> I think this was even prior to CAP (but maybe not). 

It's not in RFC-2445; I searched for "duration", but there was no 
definition of how DTEND and DURATION relate.  And, of course, 2445 is 
where such a definition belongs; it should not be in CAP.

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 2 Apr 2003 15:38:14 -0500

Date: Wed, 02 Apr 2003 12:35:02 -0700
   From: Doug Royer <[email-masked]>

		   DTSTART:1pm
		   DTEND:2pm

	   and

		   DTSTART:2pm
		   DTEND:3pm

This is incorrect. Section 4.6.1 (page 53) of RFC 2445 is quite
explicit:

   The "DTSTART" property for a "VEVENT" specifies the inclusive start
   of the event. For recurring events, it also specifies the very first
   instance in the recurrence set. The "DTEND" property for a "VEVENT"
   calendar component specifies the non-inclusive end of the event. For

"DTEND" is _non-inclusive_. That means the first event does not
include 2pm. The second event does include 2pm, but does not include
3pm. Both events have a duration of 1H.

Larry

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 13:48:20 -0700

> DTEND = DTSTART + DURATION

I am confused. You and I agree that DTEND is non-inclusive.
So DTSTART 1pm, DTEND 2pm is only 59 minuets, 59 seconds
in DURATION.

With a DTSTART of 13:00:00 :

  DTEND 14:00:01   14:00:00 hours - 13:00:00 hours
	= 60 minutes,  0 seconds duration.

  DTEND 14:00:00   13:59:59 hours - 13:00:00 hours
	= 59 minuets, 59 seconds duration.

And DTSTART == DTEND  is illegal per iCal:

    Description: Within the "VEVENT" calendar component, this property
    defines the date and time by which the event ends. The value MUST be
    later in time than the value of the "DTSTART" property.

Else duration would be (-1).

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 14:00:39 -0700

> is no overlap between [a,b) and [b,c).

Explain what is the difference between 'So we concluded that DTEND was the 1st 
second after the time ended' and 'the DTEND is not included in the interval'.

> to explain to them why they can't schedule another opaque event at 2:00?

So you agree with me that:

	DURATION = (DTEND - DTSTART) - 1

> where such a definition belongs; it should not be in CAP.

Several iCal fixes are in CAP because there is no such iCal-fixed draft.

--

---

From: John Stracke <[email-masked]>
Date: Wed, 02 Apr 2003 15:59:58 -0500

Doug Royer wrote:

> DTEND is non-inclusive.

That does not follow.  The more consistent interpretation would be that 
DURATION is also non-inclusive.

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 2 Apr 2003 16:07:02 -0500

Date: Wed, 02 Apr 2003 13:48:20 -0700
   From: Doug Royer <[email-masked]>

DTSTART _is_ inclusive. So DTSTART 13:00:00, DTEND 13:00:01 contains
exactly one second: 13:00:00.

DTSTART 13:00:00, DTEND 13:00:03 contains exactly 3 seconds:
13:00:00, 13:00:01, 13:00:02.

DTSTART 13:00:00, DTEND 13:01:00 contains exactly 60 seconds:
13:00:00, 13:00:01, 13:00:02, ..., 13:00:58, 13:00:59

DTSTART 13:00:00, DTEND 14:00:00 contains exactly 60 * 60 seconds, or
one hour.

Yes, bad example.

Larry

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 14:13:38 -0700

r
> include 2pm.

We agree.

 > The second event does include 2pm, but does not include

We agree - however in the original iCal thinking, the first
DID include 2pm making. And that is the change.

So, perhaps the wording needs fixed up as it was trying
to point out that overlap fact.

And if 2pm is not included (and we agree that it is not), then the
clock time for the first appointment is 13:00:00 -> 13:59:59
as 14:00 is NOT included. Making the DURATION 00:59:59 and not 1H.

--

---

From: John Stracke <[email-masked]>
Date: Wed, 02 Apr 2003 16:21:58 -0500

Doug Royer wrote:

>> This is not a good way of approaching the problem; it's highly prone 
>> to off-by-one errors.  Plus, it doesn't leave room for expanding to 
>> subsecond resolution, should that ever be useful.  Half-open 
>> intervals are the Right Thing: the DTEND is not included in the 
>> interval, so there is no overlap between [a,b) and [b,c).
>
> Explain what is the difference between 'So we concluded that DTEND was 
> the 1st second after the time ended' and 'the DTEND is not included in 
> the interval'.

The former assumes a closed interval.  With a half-open interval, the 
DTEND is when the period ends (as it should be), but the end of the 
period is not contained in the period.

The other difference is that the former assumes that the minimum 
resolution of the calendar is 1 second.  That's all we support today, 
but we shouldn't hardwire it in if we don't have to; it should be 
possible for our grandchildren to write RFC-244445, in which the time 
values include nanoseconds, without having to work around the 1-second 
assumption.

>> says "my opaque event starts at 1:00, and lasts for 1 hour", do you 
>> want to explain to them why they can't schedule another opaque event 
>> at 2:00?
>

That is absolutely not what I'm saying.  I'm saying that a user will be 
extremely surprised to find that DURATION != DTEND-DTSTART.

Clearly, DTEND=DTSTART+DURATION, so that 
PERIOD(DTSTART,DURATION)=PERIOD(DTSTART,DTSTART+DURATION), and both are 
half-open.

> Several iCal fixes are in CAP because there is no such iCal-fixed draft.

Maybe there should be; people should not have to read the CAP RFC to 
find updates to 2445.  Not every iCalendar implementer is going to use 
CAP, after all.

Remember that we can do an RFC that updates 2445 instead of obsoleting 
it, so that we don't have to repeat everything we're not changing.

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 14:46:52 -0700

> exactly one second: 13:00:00.

However the clock time of 13:00:01 is not included in the appointment.
So the clock time for the appointment is 13:00:00 -> 13:00:00
which is a DURATION of 0 seconds.

--

---

From: John Stracke <[email-masked]>
Date: Wed, 02 Apr 2003 17:04:03 -0500

> which is a DURATION of 0 seconds.

You're still thinking in terms of closed intervals.

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 15:17:50 -0700

> extremely surprised to find that DURATION != DTEND-DTSTART.

The presentation and the protocol are separate issues.
They do not equal and UI's need to be aware of this
and make it easier for the CU/CUA to do what the
user intended. (Mind reading CUA's anyone :-)

--

---

From: Dan Winship <[email-masked]>
Date: 02 Apr 2003 17:23:59 -0500

> which is a DURATION of 0 seconds.

No, just because iCalendar doesn't let you *refer* to sub-second
intervals doesn't mean they don't exist. The appointment does not extend
to 13:00:01, but it does include all of the time starting when the
second hand hits "00", until immediately before the second hand hits
"01". That's 1 second.

-- Dan

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 17:27:01 -0700

Thank you - I think I was in dense mode :-)
I get it now.

And the sort section is going away anyway in -11 per this WG request.

Thanks all of you for your patience!!!

--

---

From: Alan Davies <[email-masked]>
Date: Thu, 03 Apr 2003 11:29:01 -0500

>I do not understand what you mean by 'half open'.

This is a standard mathematical term, being correctly
applied to clarify the problem. A quick web search will provide
the definition.

>ended. Making the DURATION 59 minutes, 59 seconds.

But the duration has to be 60 minutes. As someone else pointed
out, an event that starts at 00:00:00 and ends at 00:00:01
has duration 1 minute, not zero minutes.

It should just be stated that for the purposes of calculating conflicts
the interval is considered to be half-open, with the DTEND not
included in the set.

Much clearer than hacking the duration.

>>the half-open interval [DTSTART, DTEND), but PERIOD(DTSTART, DURATION) is 
>>the closed interval [DTSTART,DTSTART+DURATION].

For Doug's benefit:

The square brackets define whether or not the endpoints are included
in the interval. [1pm, 2pm] defines that 1pm and 2pm are included,
(1pm, 2pm) implies that neither is.

I don't have a copy of ISO-8601 to hand, but I seemed to remember
that it agreed with our duration calculations, not Doug's, which
will just cause confusion and error.

--Alan

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 3 Apr 2003 15:21:29 -0500

> it, so that we don't have to repeat everything we're not changing.

I'd be in favor of this; there are a number of ambiguities and
under-specified areas in 2445's time handling, which I discovered in the
process of adapting and implementing it for CPL.

-- 
Jonathan Lennox
[email-masked]