[Ietf-calsify] Re: UNTIL as a "floating" date-time as well as UTC date-time + Unrelated RFC Typo/Bug

Mon Apr 3 14:55:49 PDT 2006

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 3. April 2006 22:46 schrieb ME:
> Desired:
> Allow for UNTIL to use "floating time" when a valid ";TZID=" is specified
> in the DTSTART.

That creates problems when the UNTIL time happens just at a time zone shift. 
E.g. take a recurrence with the following setting:
  UNTIL;TZID=Europe/Vienna:20060326T023000
In fact, there is no 2:30 here in Vienna, since the hour between 2:00 and 3:00 
is simply cut out. In that case you can solve the problem by arguing that the 
UNTIL is meant that no event occurs after 2:30.

On the other hand, when shall an hourly recurrence with 
  UNTIL;TZID=Europe/Vienna:20061029T023000
end? There are two 2:30 on that day (when summer time ends)...

Only if this ambiguity is resolved (in a way that allows recurrences that end 
on the first 2:30 and that allows recurrences that end on the second 2:30), 
using UNTIL in local time is a good idea.

(Actually, I started writing that mail before reading to the end. I even argue 
below that this is nothing special for the UNTIL, but a general problem, 
which is nowhere solved in the RFC).

> On to UNTIL...
>
> ...
> "The UNTIL rule part defines a date-time value which bounds the
>    recurrence rule in an inclusive manner. If the value specified by UNTIL
> is synchronized with the specified recurrence, this date or date-time
> becomes the last instance of the recurrence. If specified as a
> date-time value, then it MUST be specified in an UTC time
>    format."
> ...
>
> "If observance is known to have an effective end date, the
>         "UNTIL" recurrence rule parameter MUST be used to specify the last
> valid onset of this observance (i.e., the UNTIL date-time will be
> equal to the last instance generated by the recurrence pattern).
> It MUST be specified in UTC time."
> ...
> First partial paragraph suggests that UNTIL does not need to be be in UTC
> unless it is as a date-time value. Does this suggests a "date" value might
> be acceptable?

Yes, but from what I understand from the discussions here and the archives, 
the types of the UNTIL and the type of the DTSTART must match (similar to the 
DTSTART and DTEND: both can be either date or date-time. Although it's 
nowhere written that the types need to match, one of the authors of rfc 2445 
explained that they actually have to match).

So, if the DTSTART is a DATE, the UNTIL must also be a DATE, but if the 
DTSTART is a DATE-TIME, the UNTIL must be, too.

> Forcing UNTIL to be in UTC seems to break modularity of TIMEZONE for
> programmers, and create an unnecessary burden to perform per-timzeone
> calculation of the proper time for the given timezone.

Absolutely. All (or rathe almost all) other TZ calculations can be done in 
local time, but for this comparison a conversion to UTC is needed!

> There is a similar problem with RDATE an its requirement to be in UTC:
> "Alternatively, the "RDATE" property can be used to define the onset
>    of the observance by giving the individual onset date and times.
> "RDATE" in this usage MUST be specified as a local DATE-TIME value in
> UTC time."
> Though RFC says RDATE must also be in UTC, rfc also includes an example
> that seems to show otherwise:
> "RDATE;TZID=US-EASTERN:19970714T083000"

Hmm, strange. The grammar defines tzidparam as a valid parameter for rdate...
I suppose the first sentence is wrong and the "in UTC time" should be 
deleted...

However, again we have the same problem: 
  RDATE;TZID=Europe/Vienna:20061029T023000
Does this mean the first or the second 2:30?

> DTEND in FREEBUSY could also benefit from floating times when DTSTART
> includes ;TZID=

Actually, the requirement that FREEBUSY MUST be in UTC makes working with F/B 
lists so easy because you don't have to care about all the various timezones 
at all. Simply load the times, and convert them from UTC to your local time 
zone (for which there are OS calls available, so no ical library handling the 
TZs is necessary).

> A solution in the RFC?
>
> This next section seems to suggest that "floating" time may be used for
> what I describe above. 

Nope. A time
  DTSTART:20060403T230000
means 23:00 in the viewer's local time zone. If viewed by me, that's 23:00 
CEST, if viewed on the US east cost, it's 23:00 EST (or EDT?), etc.
So that time is not the same (absolute) time for everyone.

> For this, a local client would know about its own timezone, and be able to
> report to the ORGANIZER of an invalid UNTIL. Actually, this invalid UNTIL
> could also be at issue for DTSTART that start with an inavlid time. As a
> result, such an arguement can be applied to DTSTART being forced to UTC
> for the same reason. As a result, this de-values this as a sufficient
> reason to deny "floating times" in UNTIL while TZID is permitted in
> DTSTART.
> A similar reply was provided by:
> From: Jonathan Lennox <lennox at cs.columbia.edu>
> "But the same thing's true for every other DATE-TIME in a recurrence
> (DTSTART, DTEND, etc.) -- and indeed in a calendar object.  Why is UNTIL
> special?"

Exactly, that's a general problem that at time zone shifts, one hour in local 
time either doesn't exists, or exists twice. There is no indication in the 
RFC how to solve this ambiguity.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna, 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEMZnlTqjEwhXvPN0RAm2PAJ4lRRbvHoLegsj2XpxG0AXzbnIClgCeP3Ui
70KwjqxPHJK0tgpLEqlRBio=
=15Si
-----END PGP SIGNATURE-----