Notes on DTSTART & DTEND
Return to Development: Documentation & Tips
The following is a collection of (edited) exchanges on DTSTART and DTEND from mail-list exchanges which illustrate the difficulty of interpreting the rfcs correctly.
---------------------------------------------------------------- rfc2445 is unclear if the DTEND is inclusive or exclusive when both the DTSTART and DTEND are DATEs. ----------------------------------------------------------------- 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 ------------------------------------------------------ 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 -------------------------------------------------------------------- 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. > In practice, Apple's iCal always exports .... 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. -------------------------------------------------------------------- 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: >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". 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. -------------------------------------------------------------------- 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. 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 -------------------------------------------------------------------- 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. The problem then is that DTEND and DURATION are not required. If you have only a DTSTART, e.g. DTSTART;VALUE=DATE:20050101 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 DTSTART;VALUE=DATE:20050101 DTEND;VALUE=DATE:20050102 Cheers, Reinhold * -------------------------------------------------------------------- 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 * -------------------------------------------------------------------- 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 ------------------------------------------------------------------- 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. ------------------------------------------------------------------- Where does it leave us? DATE-TIME start, no end -- zero time at indicated time DATE-TIME start, DATE end -- is that allowed, means remainder of day? DATE-TIME start, DATE-TIME end -- from start, up to, not including end DATE start -- all day event DATE start, DATE end -- end - start + 1 all day(s) -------------------------------------------------------------------
