Closed Bug 357272 Opened 15 years ago Closed 15 years ago

All day events have DTEND one day past the correct DTEND

Categories

(Calendar :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: edoverton, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Thunderbird 1.5.0.7, Lightning 0.3 (buid 2006100618)

I see this issue when working with calendar export to an ics file, but by looking at bug 306157, it seems the issue may be a larger scope (see the update at 2005-11-09 00:25 by Torsten Lilge).

I did an export of my calendar and then imported it into bitpim.  In bitpim, my all day events from Lightning were showing up with an extra day.  So I reported the problem:

http://sourceforge.net/mailarchive/message.php?msg_id=36800432

This was the reply:

http://sourceforge.net/mailarchive/message.php?msg_id=36961312

In that reply, there is a link to a post from Frank Dawson (one of the editors of the applicable RFC) that clarifies how DTEND should be handled when it's in DATE format.  In short, the DTEND date should be included in the event.

http://www.imc.org/ietf-calendar/archive1/msg03648.html

So, the following is actually a two day event, not a one day event (as described in 306157):

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

In agreement with that entry spanning two days, here's a quote from the RFC (section 4.6.1) - see the last sentence:

   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).

This bug may be related to 333362 and 129660.

Reproducible: Always

Steps to Reproduce:
1. Create a single day, all-day event
2. Export the calendar as an ICS


Actual Results:  
The ICS entry for the event has its DTSTART as a different date than DTEND.

Expected Results:  
The ICS entry should have its DTSTART and DTEND in agreement.
Try again, RFC 2445 says:
   The "DTEND" property for a "VEVENT"
   calendar component specifies the non-inclusive end of the event.

Since the DTEND is exclusive, adding another day for a single day event is correct, otherwise the event would span no time.

This should be marked invalid in my mind.
Yes, the RFC does have conflicting statements.  That's why I included the link to Dawson's post that clarifies the RFC.  His clarification is that it's a two day event:

> > I agree that the RFC does not seem very clear for the DTEND of an
> > event.  A clarificaiton on the meaning of the term "non-inclusive"
> > would be good.  Editors?  I would think that if an event had
> > DTSTART:199900801 and DTEND:19990802 then that would equal 2 full
> > days of busy time (from 19990801000000Z to 19990802235959.  Correct?
>
> We explicitly got feedback to add the "non-inclusive" term. It means up
> to "T235959". Yes, you are correct in your interpretation. Similarly, a
> DTSTART;VALUE=DATE:19990730 means "-T000000" to "-T235959".

So it's a two day event per one of the RFC editors.
I don't really care about what an rfc-editor says in an email, i care about what the rfc says. And I can't find any hints in the rfc that the end-date should be non-inclusive for date-only dtend's. I can only find hints that say that dtend is always non-inclusive.

But when  in doubt, check what other implementations do.How do outlook, evolution and iCalendar handle this (for importing and exporting ics)?
Here's kde's fix to include DTEND DATE values (they state that evolution will do the same):

   http://lists.kde.org/?l=kde-commits&m=112550004803751&w=2

The RFC hint that a DTEND DATE value is inclusive is as I noted before.  In cases where the VEVENT uses a DTSTART DATE value:

   ... 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).

So a VEVENT using DATE values spans more than one date when the DTEND value is after the DTSTART value.  DTSTART of 20051107 and DTEND of 20051108 is exactly that case - this event spans more than one date.
Wow, that's the most obscure hint i've ever seen in an rfc.
Why should a parenthetical implication carry more weight than an explicit statement later in the document?
I'll say this piece and then shut up and let you all decide whether to change anything.

Yes, it's somewhat obscure, and yes, it's parenthetical.  What's missing from the RFC is a clear statement of the non-inclusive nature of a DTEND DATE value.  From what I've read, I take it to be that the non-inclusive aspect is applied to the last minute of the day, instead of the first minute of the day.  That notion is reinforced by the previously mentioned post and RFC snippet, along with cases where there's no explicit DTEND.

   ... 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.

So that's an event that spans 24 hours.  Note that what they say is that the non-inclusive end is taken as the end of the date (which aligns with what I'm arguing), not that the non-inclusive end is the next day (which aligns with the current implementation).  From what I'm arguing, that would mean the implicit DTEND value is identical to the DTSTART value - which is exactly what the RFC says to do for DATE-TIME values (note that a missing DTEND value for DATE means a 24 hour span, but a missing DTEND for DATE-TIME means a 0 minute span).

If nothing else, single day all-day events could be coded without a DTEND value, and that would ensure there's a clear direction from the RFC regarding how it should be handled.
We can discuss the meaning of the rfc forever, but there is only one thing i care about: what do other apps do? Please test outlook, evolution and icalendar before continuing the discussion.
I don't have access to evolution or iCal.  I'll try Outlook.
Outlook's implementation agrees with the current implementation - the import excludes the DTEND day.

Similarly, google calendar's implementation agrees with the current implementation (both import and export exclude the DTEND day).

For what it's worth, I had to add METHOD:PUBLISH to get Outlook to recognize the file at all, and at that point it had timezone issues.  I removed the timezone information and that improved matters;  the import processed on day boundaries instead of 4am.  The timezone problems very well could be something with my Outlook setup - I'm not that savvy a user there.
I found the following example useful to understand the syntax:

> 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

http://lists.osafoundation.org/pipermail/ietf-calsify/2005-September/000769.html
That thread indicates that most other clients interpret the dtend like sunbird does. So unless that is wrong or has changed now, this bug is wontfix.
Whiteboard: [qa discussion needed]
Per Michiel's last comment, I've also verified that iCAL.app is behaving the same way that Sunbird is behaving. 

Reporter et al, I recommend we take this issue to the  calconnect ietf calsify mailing list and see if we can get the RFC's issues resolved.

Marking as WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Whiteboard: [qa discussion needed]
Duplicate of this bug: 393810
You need to log in before you can comment on or make changes to this bug.