RE: Recurring Anniversary Instances?

["Dan Hickman" <dhickman@xxxxxxxxxxxxxxxxxx>]

Bruce,

 

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.

 

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?

 

Dan

> Before hopping into this exchange I 
>     would like to get some group clarification/acceptance of something: 
>     
>
> Is DTSTART;VALUE=DATE:19990730 
>     equivalent to DTSTART;VALUE=DATE-TIME:19990730T000000Z?
>
> Is DTEND;VALUE=DATE:19990730 equivalent to 
>     DTEND;VALUE=DATE-TIME:19990730T235959Z (or should that be 
>     DTEND;VALUE=DATE-TIME:19990801T000000Z since its 
>     "non-inclusive")? 
>
> RFC 
>     2445 has only the following relevant text (for DTSTART): 
>     
>
>    The "VEVENT" is also the 
>     calendar component used to specify an
>   anniversary or daily 
>     reminder within a calendar. These events have a
>   DATE value type 
>     for the "DTSTART" property instead of the default
>   data 
>     type of DATE-TIME. If such a "VEVENT" has a "DTEND" 
>     property, it
>   MUST be specified as a DATE value also. 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).
>
>    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. 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. [Snip] 
>
> 4.8.2.4 Date/Time Start
>
>   [Snip]
>
>   Value 
>     Type: The default value type is DATE-TIME. The time value MUST
>   be 
>     one of the forms defined for the DATE-TIME value type. The value
>   
>     type can be set to a DATE value type.
>
>   [Snip] 
>     
>
>   Description: Within the "VEVENT" 
>     calendar component, this property
>   defines the start date and time 
>     for the event. The property is
>   REQUIRED in "VEVENT" 
>     calendar components. Events can have a start
>   date/time but no end 
>     date/time. In that case, the event does not take
>   up any 
>     time.
>
> There is no explicit 
>     declaration of what the start (or end) time default to in the VALUE=DATE 
>     cases.   Before continuing Id like to get concensus (or 
>     murmers)... 
>
> BTW: One potential 
>     example of Dans case is an IETF meeting.  It could be "a repeating 
>     all day" entry on my calendar for Monday thru Thursday and only 
>     "half a day" on Friday (using an RDATE;VALUE=PERIOD:...).  
>     (Yes, your pending counter example of "a repeating 9AM-6PM" entry 
>     for Monday thru Thursday and 9AM-12PM Friday is another way to describe the 
>     same thing; its all in how the CU wants to treat it!) 
>
> Bruce 
> ===========================================================================
> Bruce 
>     Kahn                     
>                INet: Bruce_Kahn@iris.com
> Iris 
>     Associates                   
>            Phone: 978.392.5335
> Westford, MA, USA 01886 
>                        FAX: 
>     and nothing but the FAX...
> Standard disclaimers apply, even where 
>     prohibited by law...