[Ietf-calsify] dtstart in tz or utc time and dtend in floating time

[Arnaud Quillaud]

> -----Original Message-----
> From: ietf-calsify-bounces at osafoundation.org
> [mailto:ietf-calsify-bounces at osafoundation.org]On Behalf Of 
> Mike Samuel
> Sent: Friday, March 30, 2007 1:23 AM
> To: Reinhold Kainhofer
> Cc: ietf-calsify at osafoundation.org
> Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in
> floating time
> 
> 
> If I understand the questions, Arnaud is not asking about different
> value types, but about start and ends that are both date-times but
> where one is in a timezone and one is floating, so:
> 
>   DTSTART;TZID=America/Los_Angeles:20060329T161900
>   DTEND:20060329T164900
> 
> I don't think this introduces problems with start dates after end
> dates that you can't already run into when both DTSTART and DTEND have
> TZIDs.

I think it is a different scenario, especially when you start to think in terms of iTIP workflow or CalDAV calendar-query.

When both DTSTART and DTEND have TZIDs, the event (or at least a single instance of an event) can be translated into the same UTC time start/end pair by the Organizer and Invitees without ambiguity. If the event is valid on the Organizer's side (end must be after start), it will be valid for all attendees, wherever they might be in terms of their local timezone.

When the DTSTART has TZID (or UTC) and the DTEND is floating (could be the opposite as well), the event might be absolutely valid on the Organizer side (end must be after start) but it might be invalid on the attendee side. For example, if you (in the US, PST) invite me (in France, CET) with the dates mentioned above, the event is valid from your perspective but invalid for me.

Same for CalDAV calendar-query where you can choose in which timezone you want to represent floating times.

Arnaud Q


> 
> mike
> 
> 
> 
> On 29/03/07, Reinhold Kainhofer <reinhold at kainhofer.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Am Donnerstag, 29. März 2007 schrieb Petr Tomasek:
> > > > 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.
> > >
> > > But You would have no way to express events like:
> > > "event X starts on friday xy at 18:00 and ends on sunday xy".
> > >
> > > If You force both DTSTART and DTEND to be the same type, then
> > > this event would be transformed into:
> > > "event X starts on friday xy at 18:00 and ends on sunday 
> xy 24:00",
> > > which is not the same!
> >
> > Frank Dawson, one of the authors of rfc 2445, says in the 
> following mail that
> > it was the intention of rfc 2445 that DTSTART, DTEND, 
> UNTIL, etc. have the
> > same value type. It was just not stated clear enough (yeah, that's a
> > euphemism for "not at all") in the original RFC:
> >
> > http://www.imc.org/ietf-calendar/archive1/msg03648.html
> >
> > See also the summary of the whole discussion on
> > http://tipi.sourceforge.net/doc/recur/apa.html
> >
> > Cheers,
> > Reinhold
> >
> >
> >
> > - --
> > - ------------------------------------------------------------------
> > Reinhold Kainhofer, Vienna University of Technology, Austria
> > email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
> >  * Financial and Actuarial Mathematics, TU Wien, 
http://www.fam.tuwien.ac.at/
>  * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
>  * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGDDK4TqjEwhXvPN0RAjhPAKCkdCt53lYsK5XNAg6aeyO9jt4RAACfZY/E
> wxDHhSQwsTPP3RZOpzBQLDs=
> =IKwK
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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