RE: Recurring Anniversary Instances?

[Frank_Dawson@xxxxxxxxx]

>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