Subject: RE: Recurring Anniversary Instances?

From: [email-masked]
Date: Fri, 30 Jul 1999 18:43:39 GMT

>Technically, a DATE type value cannot be considered equal to a DATE-TIME 
value because the types are different.  A >DATE-TIME value specifies a 
specific point in time, whereas a DATE value actually can be thought of as 
specifying a >range of time (19990730000000Z to 19990730235959).  Hence, 
"All-Day".  This is useful concept when calculating Free >Busy time 
because you would show the whole day as being busy.

Bruce's point is that if you had a recurrence where the DTSTART and DTEND 
were of DATE-TIME value types and the RDATE/EXDATE were with DATE value 
type, you could assume the "TIME" piece for the RDATE/EXDATE values were 
to be the same as that in the DTSTART/DTEND. This is much more appropriate 
than allowing conflicting value types in the DTSTART/DTEND and 
RDATE/EXDATE. For example, what do you do with the VALARMs for those 
occurences specified by the RDATE values? Should that repeating alarm 
really go off at 9:00 AM after all? This is one reason why strong, 
consistent "value typing" across the DTSTART, DTEND or DURATION, RDATE, 
EXDATE and RECURRENCE-ID needs to be a MUST! This was the intent of the 
iCalendar specification. Fine, we need to clarify the text in iCalendar. 
 
>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". 
NOTE: Your DATE-TIME values were invalid syntax, as they did not have the 
"T" time separator. You also left out the ";VALUE=DATE" to over-ride the 
default DATE-TIME value type. But you may have known this.
-- Frank

---

From: "Dan Hickman" <[email-masked]>
Date: Fri, 30 Jul 1999 15:07:13 -0500

Frank,

That is fine by me if everyone else agrees.  I can remove the functionality.

Does everyone agree that date type (DATE or DATE-TIME) must be consistent
for all values in an event?

Dan
    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
    Sent: Friday, July 30, 1999 1:44 PM
    To: [email-masked]
    Subject: RE: Recurring Anniversary Instances?

    >Technically, a DATE type value cannot be considered equal to a
DATE-TIME value because the types are different.  A >DATE-TIME value
specifies a specific point in time, whereas a DATE value actually can be
thought of as specifying a >range of time (19990730000000Z to
19990730235959).  Hence, "All-Day".  This is useful concept when calculating
Free >Busy time because you would show the whole day as being busy.

    Bruce's point is that if you had a recurrence where the DTSTART and
DTEND were of DATE-TIME value types and the RDATE/EXDATE were with DATE
value type, you could assume the "TIME" piece for the RDATE/EXDATE values
were to be the same as that in the DTSTART/DTEND. This is much more
appropriate than allowing conflicting value types in the DTSTART/DTEND and
RDATE/EXDATE. For example, what do you do with the VALARMs for those
occurences specified by the RDATE values? Should that repeating alarm really
go off at 9:00 AM after all? This is one reason why strong, consistent
"value typing" across the DTSTART, DTEND or DURATION, RDATE, EXDATE and
RECURRENCE-ID needs to be a MUST! This was the intent of the iCalendar
specification. Fine, we need to clarify the text in iCalendar.

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

    NOTE: Your DATE-TIME values were invalid syntax, as they did not have
the "T" time separator. You also left out the ";VALUE=DATE" to over-ride the
default DATE-TIME value type. But you may have known this.

    -- Frank