Subject: dtend/dtstart date value in sample iCalendar DTD Document (xCal)

From: "ArentJan Banck" <[email-masked]>
Date: Mon, 5 Aug 2002 13:56:36 +0200

Hi,
The sample on page 25  draft-ietf-calsch-many-xcal-02.txt says:

      <vevent>
           <uid>[email-masked]</uid>
           <dtstamp>19990101T130000Z</dtstamp>
           <dtstart value="DATE">19991102</dtstart>
           <dtend value="DATE">19991102</dtend>
           ...

As RFC 2445 says dtend MUST be later in time then the value of the "DTSTART"
property, I would assume that setting dtstart and dtend to the same date
value is incorrect.
To specify a one-day event, shouldn't only DTSTART be set to a DATE value,
without a DTEND property?

ArentJan

---

From: Doug Royer <[email-masked]>
Date: Mon, 05 Aug 2002 09:05:59 -0600

ArentJan Banck wrote:
> As RFC 2445 says dtend MUST be later in time then the value
> of the "DTSTART" property, I would assume that setting dtstart
> and dtend to the same date value is incorrect.
>
> To specify a one-day event, shouldn't only DTSTART be set to a
> DATE value, without a DTEND property?

Yep, thanks, I just updated the draft and removed dtend.
It will be in the next push.

FYI - xcal discussions generally take place on
[email-masked] .

---

From: Gary Frederick <[email-masked]>
Date: Mon, 05 Aug 2002 10:40:50 -0500

Doug,

Since joining [email-masked] is now open to everyone, I'll get back on.

Thanks,

Gary

---

From: Gary Frederick <[email-masked]>
Date: Mon, 05 Aug 2002 10:53:09 -0500

Doug, could we have a bit of conversation about this?

rfc2445 states

   The following is an example of the "VEVENT" calendar component used
   to represent an anniversary that will occur annually. Since it takes
   up no time, it will not appear as opaque in a search for busy time;
   no matter what the value of the "TRANSP" property indicates:

     BEGIN:VEVENT
     UID:[email-masked]
     DTSTAMP:19970901T1300Z
     DTSTART:19971102
     SUMMARY:Our Blissful Anniversary
     CLASS:CONFIDENTIAL
     CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
     RRULE:FREQ=YEARLY
     END:VEVENT

If the xCal example was to show a one day event, removing the DTEND will make it take up no time and that is probably not what is wanted.

I suggest the text in rfc2455 be changed to say that a DTEND should be 'equal to or' greater than the DTSTART. And I guess we would have to say that if it's equal to, the 'duration' is that day.

Will that cause other problems?

Gary

---

From: Doug Royer <[email-masked]>
Date: Mon, 05 Aug 2002 10:48:33 -0600

Gary Frederick wrote:
> If the xCal example was to show a one day event,
> removing the DTEND will make it take up no time and that
> is probably not what is wanted.

Just like with iCal - if you want it to consume time, then
make DTEND greater than DTSTART.

The example in xcal should not have a DTEND, just like
the iCal representation did not in 2445 as you point out.

It is clear to me that the xcal example is showing exactly
how a repeating anniversary is represented exactly
like the same entry in iCal.

> I suggest the text in rfc2455 be changed to say that a DTEND should
> be 'equal to or' greater than the DTSTART. And I guess we would have
> to say that if it's equal to, the 'duration' is that day.

I would say - no. We had debates about this. If you want
to represent time, make DTEND larger than DTSTART or
use DTSTART and DURATION.

> Will that cause other problems?

A DTSTART and a DTEND with the same value will look like a
busted iCalendar object according to 2445 compliant CUAs, so it
would be an incompatible change. And there is compatible solution:
use DTEND or DURATION.

---

From: Gary Frederick <[email-masked]>
Date: Mon, 05 Aug 2002 12:29:29 -0500

DURATION!

Part of the original question was how to represent a day long event. Let me make sure I have it right.

Use case #1

  DTSTART;DATE:19971102

with no DTEND/DURATION is an event that takes up no time.

Use case #2

  DTSTART;DATE:19971102
  DTEND;DATE:19971102

incorrect. DTEND is the same time as DTSTART

Use case #3

  DTSTART;DATE:19971102
  DTEND;DATE:19971103

Valid and represents time.

Use case #4

  DTSTART;DATE:19971102
  DURATION:PT12H

Valid and represents time - 12 hours.

====
So you can represent an anniversary with Use case #1 and an one day event (12 hours long) with Use case #4.

How long is use case #3? 24 hours? DTEND is the non-inclusive end of the event. If so, would that be a way to represent an event that was on 19971102? Seems like it to me.

Gary

---

From: Doug Royer <[email-masked]>
Date: Mon, 05 Aug 2002 11:58:16 -0600

Gary Frederick wrote:
> 
> DURATION!
> 
> Part of the original question was how to represent a
> day long event. Let me make sure I have it right.

(part of your question - not the original - correct?)

The original question ("ArentJan Banck" <[email-masked]>)
was:

   >...To specify a one-day event, shouldn't only DTSTART be set
   > to a DATE value, without a DTEND property?

And the answer was yes.

> How long is use case #3? 24 hours? DTEND is the non-inclusive
> end of the event. If so, would that be a way to represent an
> event that was on 19971102? Seems like it to me.

Yes - #3 represents a 24 hour one day event. I think this
is a topic that was debated within the last year on calsch.
As I recall, 2445 only talked about 'date-time', and I think the WG
concluded that it also applied to 'date' when time was not
supplied.

 Note: The original from page 25 of xcal as noted in the original
 email - has an RRULE. Just in case someone thinks I was responding
 to that one :-)

---

From: Gary Frederick <[email-masked]>
Date: Mon, 05 Aug 2002 13:27:58 -0500

> (part of your question - not the original - correct?)
No. The original.
>    > to a DATE value, without a DTEND property?

Use case #1 is good for documenting an anniversary, something that does not need to take up time.

I understood that the original question was about a one day event and I read it as an event that DID take time, one day - Use case #3 as you said below.

> concluded that it also applied to 'date' when time was not

I don't think it's worth modifying 2445, is there a faq that could clarify this and other points?

Thanks,

Gary