Subject: [Ietf-calsify] All Day Events and DTEND

From: cmtalbert at gmail.com (Clint Talbert)
Date: Tue Jan 23 09:38:50 2007

I hope you can help clear up a misunderstanding we have encountered 
about DTEND values for all-day events.  A far more detailed discussion 
of the problem can be found in this bug report: 
https://bugzilla.mozilla.org/show_bug.cgi?id=357272.  I will attempt to 
summarize the salient points.

In several applications an event with the DTSTART and DTEND below is 
interpreted as a one day duration, all-day event.

DTSTART;VALUE=DATE:20051107
DTEND;VALUE=DATE:20051108

However, in other applications, this is interpreted as a two day 
duration, all-day event.

The confusion stems from two seemingly contradictory portions of RFC 2445.

The people in the one day duration camp use this bit of text as their 
justification:

The "DTEND" property for a "VEVENT"
calendar component specifies the non-inclusive end of the event.

The people in the two day duration camp use this bit of text from the 
RFC as their justification:

The "VEVENT" is also the calendar component used to specify an
anniversary or daily reminder within a calendar. These events have a
DATE value type for the "DTSTART" property instead of the default
data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
MUST be specified as a DATE value also. 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).

Previously, it seems that this issue has come up on this list once before:
http://lists.osafoundation.org/pipermail/ietf-calsify/2005-September/000769.html

There it was decided that the DTEND should be exclusive of the event 
(i.e. the interpretation used by the one day duration camp is correct).

Could we address this conclusively with some text or some examples in 
the next revision of the RFC?  I have not read the bis-04 version yet in 
its entirety, and I apologize if this is already addressed.

Thank you very much,

Clint

---

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Tue Jan 23 10:40:32 2007

Hi Folks,

> about DTEND values for all-day events.  A far more detailed
> discussion of the problem can be found in this bug report: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=357272.  I will attempt
> to summarize the salient points.

+1 on getting more explicit about this issue in the RFC, Chandler went
through a very similar debate to the one Mozilla outlines in that bug.

I think it's probably worth an expository paragraph given that the the
vernacular interpretation (January 23-January 24 has duration of two
days) is both completely reasonable and wrong in the context of rfc2445.

Sincerely,
Jeffrey

---

From: lists at block-online.eu (Oliver Block)
Date: Tue Jan 23 12:55:23 2007

> However, in other applications, this is interpreted as a two day

<quote>
4.8.2.2 Date/Time End

   Property Name: DTEND

[...]

   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.

[...]

</quote>

This prohibits 

DTSTART;VALUE=DATE:20051107
DTEND;VALUE=DATE:20051107

If you just use

the RFC states:

<quote>
   Events can have a start
   date/time but no end date/time. In that case, the event does not take
   up any time.
</quote>

So how is it possible to define an all day event using DATE type, if not?

> DTEND;VALUE=DATE:20051108

Regards,

Oliver

-- 
Leben ist mehr als ... 
<http://www.nak-nrw.de/index.php?id=71>

---

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Tue Jan 23 13:09:12 2007

Hi Oliver,

>> DTEND;VALUE=DATE:20051108

Ah, but in a gloriously distributed and thus confusing fashion, this is
overridden by:

4.6.1 Event Component

[...]

   The "DTEND" property for a "VEVENT"
   calendar component specifies the non-inclusive end of the event. 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.

Sincerely,
Jeffrey

---

From: lists at block-online.eu (Oliver Block)
Date: Tue Jan 23 15:13:15 2007

Hello Jeffrey,

>    non-inclusive end is the end of the calendar date specified by the

I would not say that it's overriding. 4.6.1. says it ends with the day and 
4.8.2.2 says it does not take up any time, which means - if I understand the 
term 'take up time' right (I usually don't use it) - occupies no time for 
that day, like a birthday. So it will not appear in a freebusy component.

Best Regards,

Oliver

---

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Tue Jan 23 15:29:59 2007

Hi Oliver,

> that day, like a birthday. So it will not appear in a freebusy component.

I had the same idea when I read through the RFC a few years ago.
Regardless of whether that was the RFC authors' intent, I believe that
most (if not all) existing calendar software doesn't interpret all-day
DTSTART values this way.

I don't think vendors are going to shift how they handle this.  We
should clarify the RFC to reflect the way all-day events (with and
without DTENDs) are actually handled in the wild.

Sincerely,
Jeffrey

---

From: TimHare at comcast.net (Tim Hare)
Date: Tue Jan 23 20:01:47 2007

I think we should not change the RFC to match what's in the wild unless
what's in the wild makes sense from an end-user and also implementer
standpoint; not to mention the fact that you have different implementations
in the wild, so what do you choose?

I believe that the original authors had to choose: either the DTEND value
was inclusive or it wasn't (as simple as that) - and apparently they found
more use cases or made more sense of the case where DTEND meant "the event
ends just before" the value. For the simplest case I can think of, the
duration of 00:00 to 23:59 (DTEND = DTSTART +1 , NON-inclusive) when
measured in minutes equals 24 hours and 0 minutes, whereas 00:00 to 00:00
on the next day (inclusive DTEND) is a duration of 24:01. So, my
somewhat-educated guess is that this was chosen to provide easy interchange
between DURATION and DTSTART/DTEND. When VALUE=DATE it provides an all-day
event (DTEND = DTSTART + 1) with duration of 24 hours, and also for the
birthday/anniversary/make a note on the calendar case where you have DTSTART
and no DTEND and a duration of 0 hours, without having to include the time
value in either case.  

I've stated what I believe about original intent, and you've stated your
belief about existing software - but, do we have a source of facts to go to?
Does someone from CalConnect or Calsisfy-WG have documented what different
implementations do with this?

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey Harris
Sent: Tuesday, January 23, 2007 6:29 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] All Day Events and DTEND

Hi Oliver,

> 4.8.2.2 says it does not take up any time, which means - if I 
> understand the term 'take up time' right (I usually don't use it) - 
> occupies no time for that day, like a birthday. So it will not appear in a
freebusy component.

I had the same idea when I read through the RFC a few years ago.
Regardless of whether that was the RFC authors' intent, I believe that most
(if not all) existing calendar software doesn't interpret all-day DTSTART
values this way.

I don't think vendors are going to shift how they handle this.  We should
clarify the RFC to reflect the way all-day events (with and without DTENDs)
are actually handled in the wild.

Sincerely,
Jeffrey
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: andrew_dowden at softdesign.net.nz (Andrew N Dowden)
Date: Tue Jan 23 20:43:10 2007

> in the wild, so what do you choose?
+1

  SoftDesign Group
  Dowden Software Associates
  P O Box 31 132, Lower Hutt 5040, NEW ZEALAND

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Jan 24 03:08:28 2007

Am Mit J?n 24 2007 schrieb Tim Hare:
> ends just before" the value. 

No, to the contrary, the original authors explicitly stated in a mail that the 
DTEND DATE value was actually the last day of the event. "Non-inclusive" in 
this case was referring to the end of the DTEND date. 

In particular, 
DTSTART;VALUE=DATE:20051107
DTEND;VALUE=DATE:20051108
should be a two-day event.

It's only the implementors who completely misunderstood the (admittedly not 
very clear) wording of the RFC in this case!

If you interpret the RFC that way, the contradictions suddently all vanish, 
and the iCalendar contents is also easily understandable in clear-text.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

---

From: lear at cisco.com (Eliot Lear)
Date: Wed Jan 24 03:08:35 2007

While the issues list for 2445bis is officially closed, since I don't 
see a non-normative change in the text coming out of this discussion, I 
wouldn't object if someone proposed some example text to make the matter 
clear.  Please copy Bernard and this group directly on any such text.

Eliot

---

From: lear at cisco.com (Eliot Lear)
Date: Wed Jan 24 03:08:40 2007

While the issues list for 2445bis is officially closed, since I don't 
see a normative change in the text coming out of this discussion, I 
wouldn't object if someone proposed some example text to make the matter 
clear.  Please copy Bernard and this group directly on any such text.

Eliot

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Wed Jan 24 13:28:42 2007

Eliot,

There are two issues here:

1- Handling of DTEND for day events;
2- Default duration of day events.

The 1st issue was brought up on the list in October 2005 by Chris Stoner:

http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000821.html

and I was under the impression that concensus was reached back then.
Check Reinhold's replies:

http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000823.html
http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000824.html

The 2nd issue was brought up on the list in November 2006 by myself
and it is is being tracked as issue 59 in the tracker.

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001341.html
http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue59

Cheers,
Bernard

---

From: TimHare at comcast.net (Tim Hare)
Date: Wed Jan 24 17:06:43 2007

Ahhh... That makes sense too when you use the two-day event example. And a
one-day, all-day event would then be:

With an implied beginning of 000000Z and ending of 235959Z ?

Tim Hare

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reinhold
Kainhofer
Sent: Wednesday, January 24, 2007 6:09 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] All Day Events and DTEND

Am Mit J?n 24 2007 schrieb Tim Hare:
> I believe that the original authors had to choose: either the DTEND 
> value was inclusive or it wasn't (as simple as that) - and apparently 
> they found more use cases or made more sense of the case where DTEND 
> meant "the event ends just before" the value.

No, to the contrary, the original authors explicitly stated in a mail that
the DTEND DATE value was actually the last day of the event. "Non-inclusive"
in this case was referring to the end of the DTEND date. 

In particular,

Cheers,
Reinhold

- --
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, 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
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFtz42TqjEwhXvPN0RAktVAKCScnc29PxwHTBsoVuPL7jbq72R1wCdFNMB
WGroCLJzBJDmBv0ncdgAOyk=
=LdwR

---

From: TimHare at comcast.net (Tim Hare)
Date: Wed Jan 24 17:50:07 2007

Is there a repository for calendar-specific code (such as XSLT transforms)
that people want to share?

Tim Hare

-----Original Message-----

In particular,

Cheers,
Reinhold

- --