Subject: [ietf-calsify] Clarification on DUE in TODO's in rfc2445bis

From: Satya Vempati <[email-masked]>
Date: Fri, 04 Sep 2009 16:07:48 -0700

According to the text in 
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-10#section-3.8.2.3

	This property defines the date and time before which a
      to-do is expected to be completed.  For cases where this property
      is specified in a "VTODO" calendar component that also specifies a
      "DTSTART" property, the value type of this property MUST be the
      same as the "DTSTART" property, and the value of this property
      MUST be later in time than the value of the "DTSTART" property.
      Furthermore, this property MUST be specified as a date with local
      time if and only if the "DTSTART" property is also specified as a
      date with local time.

Does this mean that even when the DTSTART property type is DATE, DUE has to be greater than DTSTART? Why can't they be equal? Isn't it possible to have to-do's that start and are due on the same day?

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

---

From: "Tim Hare" <[email-masked]>
Date: Fri, 4 Sep 2009 22:13:05 -0400

It is possible, but in my opinion, that's a case where date AND time should
be used, making it easy to have the DUE value be later than the DTSTART
value.  

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Satya Vempati
Sent: Friday, September 04, 2009 7:08 PM
To: [email-masked]
Subject: [ietf-calsify] Clarification on DUE in TODO's in rfc2445bis

According to the text in

Does this mean that even when the DTSTART property type is DATE, DUE has to
be greater than DTSTART? Why can't they be equal? Isn't it possible to have
to-do's that start and are due on the same day?

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 7 Sep 2009 09:41:10 +0100

Sounds like another use case for saying something starts at 11am "ish! and 
is due by 6pm "ish".  Switching from date to date-time implies a degree of 
precision that might not be appropriate.  I'd very much like there to be 
better options for saying "I've arranged to have dinner with a friend on 
Tuesday evening", when the start/end time of that event have yet to be 
firmed up.

----- Original Message ----- 
From: "Tim Hare" <[email-masked]>
To: "'Satya Vempati'" <[email-masked]>; 
<[email-masked]>
Sent: Saturday, September 05, 2009 3:13 AM
Subject: Re: [ietf-calsify] Clarification on DUE in TODO's in rfc2445bis

---

From: "Tim Hare" <[email-masked]>
Date: Mon, 7 Sep 2009 13:17:13 -0400

A TODO could start at 00:00 and be due by 23:59 on the same date, which
satisfies the requirements as written.

I don't know the status of the RCF vis-a-vis changes as I write this, but
proposed alternate text if we need it:

>      MUST NOT be earlier in time than the value of the "DTSTART" property.
>      date with local time

I changed "MUST be later in time" to "MUST NOT be earlier in time" to allow
the DTSTART and DUE to be equal, although for most use cases that seems
illogical, and I don't necessarily agree with it.

Tim Hare

----- Original Message -----
From: "Tim Hare" <[email-masked]>
To: "'Satya Vempati'" <[email-masked]>;

> It is possible, but in my opinion, that's a case where date AND time 
> should be used, making it easy to have the DUE value be later than the 
> DTSTART value.
>
>
> Tim Hare
> Does this mean that even when the DTSTART property type is DATE, DUE 
> has to be greater than DTSTART? Why can't they be equal? Isn't it 
> possible to have to-do's that start and are due on the same day?
>
>

---

From: Satya Vempati <[email-masked]>
Date: Wed, 09 Sep 2009 11:45:00 -0700

"Must not be earlier in time" is in line with RFC 2445, which says

The value MUST be a date/time equal to or after the DTSTART value, if 
specified.

and the RFC 2445bis says

the value of this property MUST be later in time than the value of the "DTSTART" property.

This seems like a gratuitous departure from the old standard. Even 
though this is a small matter, it is important  to get the words right.