Subject: [Ietf-calsify] DTEND for day events

From: gafter at google.com (Neal Gafter)
Date: Thu Sep 1 11:08:11 2005

rfc2445 is unclear if the DTEND is inclusive or exclusive when both the 
DTSTART and DTEND are DATEs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050901/7c51d339/attachment.html

---

From: Carsten.Guenther at scalix.com (Carsten Guenther)
Date: Thu Sep 1 11:15:25 2005

Afaik RFC 2445 does not say anything about allday events, but in all  
implementations I have seen so far the DTEND is exclusive.

Example for a one day allday event on Jul 15:

DTSTART;VALUE=DATE:20050715
DTEND;VALUE=DATE:20050716

Think of this being another form for midnight to midnight local time:

DTSTART:20050715T000000
DTEND:20050716T000000

Carsten

On Sep 1, 2005, at 11:08 AM, Neal Gafter wrote:

> rfc2445 is unclear if the DTEND is inclusive or exclusive when both  
> the DTSTART and DTEND are DATEs.
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

---

From: jeffrey at skyhouseconsulting.com (Jeffrey Harris)
Date: Thu Sep 1 11:20:08 2005

Hi Neal,

> DTSTART and DTEND are DATEs.

To find the language about this, you have to look in the (not
intuitively located) VEVENT definition.  It says:

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.

It doesn't say anything specific about DATE valued events, so DTEND is
always exclusive.

In practice, Apple's iCal always exports one-day all-day events with an
explicit DTEND of the day after the start.  I scratched my head about
that for a while, too, till I looked in VEVENT.

Sincerely,
Jeffrey Harris

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Thu Sep 1 12:44:31 2005

Anybody have text to propose for RFC2445 bis to improve the clarity of 
this?

lisa

---

From: olivierg at apple.com (Olivier Gutknecht)
Date: Thu Sep 1 12:59:01 2005

Hi Jeffrey,

> It doesn't say anything specific about DATE valued events, so DTEND is

Which also makes sense with the DATETIME case (i.e. a 'ponctual' event):
"For cases where a "VEVENT" calendar component
    specifies a "DTSTART" property with a DATE-TIME data type but no
    "DTEND" property, the event ends on the same calendar date and time
    of day specified by the "DTSTART" property.

> that for a while, too, till I looked in VEVENT.

I'm not sure it's 'always'. I think that with our implementation you  
might get in
some cases a  one-day DATE valued event without a DTEND.

Ol.

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Sep 1 14:05:55 2005

> implementations I have seen so far the DTEND is exclusive.

Then please see the following mail by Frank Dawson, who is one of the original 
authors of rfc 2445:
http://www.imc.org/ietf-calendar/archive1/msg03648.html

In particular:
'We explicitly got feedback to add the "non-inclusive" term. It means up to 
"T235959".'

I found this mail only recently, and so far (from KDE 3.1 until 3.4.2) we 
(=Korganizer and Kontact resp.)also interpreted non-inclusive to mean that 
DTEND should be the first date after the event. A while ago I also talked 
with one of the evolution developers and he agreed that if Frank's mail is 
true, we might have misunderstood rfc 2445.

So, the question is now what to do about this. Shall we stick to the 
interpretation that "non-inclusive" means that DTEND needs to be first date 
after the item? Or shall we use the correct interpretation from now on? 

The reason I'm asking is that we are releasing KDE 3.5 shortly, and currently 
I fixed it to use Frank's interpretation. 

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer maintainer

---

From: jeffrey at skyhouseconsulting.com (Jeffrey Harris)
Date: Thu Sep 1 14:28:15 2005

> 'We explicitly got feedback to add the "non-inclusive" term. It means up to 

Wow.  You're right, it looks like their intention was for non-inclusive
to mean not including the last minute of but including the rest of the
day.  That's sure not the way I read that language, so lets come up with
better language for 2445bis as Lisa suggests.

> I fixed it to use Frank's interpretation. 

It seems to me that there's lots of iCal data out there with the
"doesn't include the whole day" interpretation, I suspect Outlook does
the same thing.  So I'd suggest we change the language in 2445bis to say
something like:

"When a DATE value is used for DTEND no time during the given day is
included in the component, so

DTSTART;VALUE=DATE:20050101
DTEND;VALUE=DATE:20050102

represents a 24 hour period."

It's too bad there's data in the wild that means this, I really think
dates for dtends would adhere to common usage better if they were
inclusive, but ce la vies.

Sincerely,
Jeffrey Harris

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Sep 2 04:13:45 2005

Am Donnerstag, 1. September 2005 23:28 schrieb Jeffrey Harris:
> > Then please see the following mail by Frank Dawson, who is one of the
> > original authors of rfc 2445:
> > 'We explicitly got feedback to add the "non-inclusive" term. It means up
> > to "T235959".'
>

But there are other places in rfc 2445 which suggest that the DTEND is the 
last date of the event:

Sec 4.6.1: "The anniversary type of
   "VEVENT" can span more than one date (i.e, "DTEND" property value is
   set to a calendar date after the "DTSTART" property value)."

In particular that last sentence says that it's a multi-day event if DTEND is 
not eqal to DTSTART, so your example from below is a two-day event.

Sec 4.6.1: "For
   cases where a "VEVENT" calendar component specifies a "DTSTART"
   property with a DATE data type but no "DTEND" property, the events
   non-inclusive end is the end of the calendar date specified by the
   "DTSTART" property.

This last sentence is a strong indication that "non-inclusive" was intended to 
be understood the way Frank explained.

> represents a 24 hour period."

The problem then is that DTEND and DURATION are not required. If you have only 
a DTSTART, e.g. 

the above quote says that this is equivalent to

DTSTART;VALUE=DATE:20050101
DTEND;VALUE=DATE:20050101

How would you have to understand this? And what would be the difference to

Cheers,
Reinhold

- --

---

From: jeffrey at skyhouseconsulting.com (Jeffrey Harris)
Date: Fri Sep 2 08:34:00 2005

Hi Folks,

> DTEND;VALUE=DATE:20050102

If we followed what I believe iCal is doing (and what I have done in
Chandler, following iCal, but Chandler's not shipping so it can change
however we want), there would be no semantic difference between the
three examples above.

I'll freely admit I have lots of special casing in Chandler to deal with
this oddity, I'd be delighted to get rid of it.  Unfortunately, I think
given how widespread the above (admittedly not the intended by the
authors) interpretation is in actual use, we need to work with it for
VERSION:2.0 iCalendar.

We should probably find out what different implementations are doing
what with VALUE=DATE events at the upcoming CalConnect...  Perhaps if
it's just iCal, we could special case anything old iCal data, but that
sounds like a nightmare to me.

Sincerely,
Jeffrey

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Fri Sep 2 08:49:46 2005

Hi Jeffrey,

> sounds like a nightmare to me.

I treat DTEND as always being exclusive in iCalendar data - even for 
date-only values. However, when a user edits or creates an 'all-day' event, 
the displayed end time is actually the inclusive end. So I basically map 
between inclusive/exclusive values for display purposes because I found 
inclusive end to be more intuitive for users. i.e it makes more sense that 
a two day event starts on Monday and ends on Tuesday, than it does to start 
on Monday and end on Wednesday (the exclusive option).

-- 
Cyrus Daboo

---

From: cbryant-ical at corp.usa.net (Chris Bryant)
Date: Fri Sep 2 09:06:15 2005

----- Original Message ----- 
From: "Cyrus Daboo" <[email-masked]>
Sent: Friday, September 02, 2005 11:49 AM
Subject: Re: [Ietf-calsify] DTEND for day events

> date-only values. However, when a user edits or creates an 'all-day' 
> event, the displayed end time is actually the inclusive end. So I 
> basically map between inclusive/exclusive values for display purposes 
> because I found inclusive end to be more intuitive for users. i.e it makes 
> more sense that a two day event starts on Monday and ends on Tuesday, than 
> it does to start on Monday and end on Wednesday (the exclusive option).
>

We also handle DTEND like Cyrus described above.

Chris

---

From: Carsten.Guenther at scalix.com (Carsten Guenther)
Date: Fri Sep 2 09:11:24 2005

>sounds like a nightmare to me.
Unfortunately it's not just iCal. Just to name a few others that do the 
same thing: Evolution, Sunbird, Outlook/MSN and the next release of the 
Scalix server. Some vendors (Microsoft for example) also introduced 
their own property to explicitely mark an event as all-day.

Carsten

---

From: douglm at rpi.edu (Mike Douglass)
Date: Sun Sep 4 18:21:31 2005

Slightly related, is a vevent DATE DTEND allowed with a DATE-TIME 
DTSTART and if so what does it mean?

I could only find that a DATE DTSTART requires a DATE DTEND if present.

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 5 11:02:03 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050905/0144a2ae/smime.bin