Issue 65: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time

[Bernard Desruisseaux]

In section 6 Recommended Practices of RFC 2445 it says:

 > 3.  When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
 >     "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
 >     "VTODO" calendar components, have the same value data type (e.g.,
 >     DATE-TIME), they SHOULD specify values in the same time format
 >     (e.g., UTC time format).

Would we be okay to had the following MUST requirements:

If DTSTART is specified as a "DATE WITH UTC TIME" (FORM #2) or
a "DATE WITH LOCAL TIME AND TIME ZONE REFERENCE" (FORM #3) then
DTEND/DUE *MUST* be specified as either a "DATE WITH UTC TIME"
(FORM #2) or a "DATE WITH LOCAL TIME AND TIME ZONE REFERENCE"
(FORM #3).  Else, if DTSTART is specified as a "DATE WITH LOCAL
TIME" (FORM #1) then DTEND/DUE *MUST* also be specified as a
"DATE WITH LOCAL TIME" (FORM #1).

Cheers,
Bernard

Bernard Desruisseaux wrote:
> [ Note to the chairs: This issue is related to issue 65. ]
> 
> This is currently specified as a SHOULD in section 6 Recommended
> Practices of RFC 2445:
> 
>  > 3.  When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
>  >     "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
>  >     "VTODO" calendar components, have the same value data type (e.g.,
>  >     DATE-TIME), they SHOULD specify values in the same time format
>  >     (e.g., UTC time format).
> 
> I wouldn't mind adding a requirement to specify that if DTSTART is
> specified as a "DATE WITH LOCAL TIME" (FORM #1) then DTEND/DUE MUST
> also be specified as a "DATE WITH LOCAL TIME" (FORM #1).
> 
> That being said, I think we could accept DTSTART and DTEND/DUE to mix
> "DATE WITH UTC TIME" (FORM #2) with "DATE WITH LOCAL TIME AND TIME
> ZONE REFERENCE" (FORM #3).
> 
> Finally, as was already clarified for issue 65, if DTSTART and DTEND/DUE
> are both specified as "DATE WITH LOCAL TIME AND TIME ZONE REFERENCE"
> (FORM #3) a different time zone MAY be used for each property.
> 
> Cheers,
> Bernard
> 
> Arnaud Quillaud wrote:
>> The Calsify draft now clarifies in the DTEND definition that:
>> <<
>> 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.
>> (See 
>> http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001519.html). 
>>
>>
>> Nevertheless the value type just allows us to distinguish between DATE 
>> and DATETIME.
>>
>> Shouldn't we go one step further and say that if the DTSTART value 
>> type is FORM #1: DATE WITH LOCAL TIME (See 
>> http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-06.html#VALUE.DATE-TIME), 
>> DTEND should also be of the same form.
>> Otherwise, if we allow a mix of floating time + utc time (or time with 
>> tz), one can create an event which is valid in some timezones but 
>> invalid in some others (you may end up with DTEND < DTSTART).
>>
>>
>> Arnaud Q
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> Ietf-calsify at osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify