Subject: UNTIL as a "floating" date-time as well as UTC date-time + Unrelated RFC Typo/Bug

From: "ME" <[email-masked]>
Date: Mon, 3 Apr 2006 13:46:31 -0700 (PDT)

Desired:
Allow for UNTIL to use "floating time" when a valid ";TZID=" is specified
in the DTSTART.

I have done some research and looked through the two archives (pre 2000,
and 2000-) to find where is was discussed.

See the end for citations to previous threads.
I'm starting a discussion about this before following:
-> 7.3 Property Change Control

Background from RFC:

What is UTC?
"The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
properties whose time values are specified in UTC."

and date-time with UTC is?

"DATE WITH UTC TIME

   The date with UTC time, or absolute time, is identified by a LATIN
CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC
designator, appended to the time value. For example, the following
represents January 19, 1998, at 0700 UTC:

     DTSTART:19980119T070000Z"

So, UTC must include the "Z" and must not be the local time (unless local
is UTC.)

This means UTC is explicitly mutually exclusive to use of ;TZID=

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?

However, the second partial paragraph states it must be a date-time as UTC.

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.

This also inefficiently forces a re-computation of future events crossing
DST boundaries with UNTIL, if/when timezone rules change.

I'd like to suggest an alternative.

Remove the requirement for the UNTIL to be in UTC and change it to: UNTIL
MUST appear in one of two date-time values:
If the DTSTART includes a valid ";TZID=" then the date-time for UNTIL may
be representated as a "floating-time" value.
If the DTSTART does not include a valid ";TZID=" then the date-time format
for UNTIL MUST be as a UTC value.

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"

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

"Within the "VFREEBUSY" calendar component, this property defines the
   end date and time for the free or busy time information. The time MUST
be specified in the UTC time format. The value MUST be later in time
than the value of the "DTSTART" property."

However, the allowance of DTEND to be just a "date" (not just a date-time,
just so long as the value type is specified.) This partly mitigates the
timezone issues, but can create issues with border cases for events that
happen in the early morning, or late evening in timezones that are offset
from UTC less than the number of hours from their "next" or "pervious" day
(depending on their offset being plus or minus.)

However, use of just a "date" for DTEND, eliminates the end time unless a
duration or alternative is used to describe the end.

--

A solution in the RFC?

This next section seems to suggest that "floating" time may be used for
what I describe above. However, the MUST in the until counters this
"suggestion":

"In most cases, a fixed time is desired. To properly communicate a
   fixed time in a property value, either UTC time or local time with time
zone reference MUST be specified."

I'd like to see UNTIL with floating time be possible in cases where
DTSTART includes a valid ";TZID="
Responses?

Unrelated Bug?/Typo?
------------------------------------------------------------
?Added value? Possible typos:

f the trigger is set relative to START, then the "DTSTART" property
   MUST be present in the associated "VEVENT" or "VTODO" calendar
   component. If an alarm is specified for an event with the trigger set
relative to the END, then the "DTEND" property or the "DSTART" and
"DURATION' properties MUST be present in the associated "VEVENT"
calendar component. If the alarm is specified for a to-do with a
trigger set relative to the END, then either the "DUE" property or the
"DSTART" and "DURATION' properties MUST be present in the
   associated "VTODO" calendar component.

Shouldn't the above "DSTART" actually be "DTSTART"?

Previous citations:
----------------------------------------------------
(See:
 "Subject: RFC 2445: UNTIL & TZID" ,
 From owner-ietf-calendar  Fri Jun 30 07:33:11 2000

 and

 Subject: Recurrence UNTIL/RDATE/EXDATE properties with DATE values From
owner-ietf-calendar  Wed Nov  1 18:04:04 2000

 and

 Subject: Bugs(?) in RFC 2445 RECUR examples
 From owner-ietf-calendar Sun Jul  8 20:19:01 2001
Included a reason to not support "floating times":
From: "Jonathan Lennox" <[email-masked]>
    "As for having UNTIL in UTC, a value in UTC always represents one
single instant; if local time were used, then due to daylight shifts, a
particular value could represent 1, 2, or a non-existant instant."

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 <[email-masked]>
"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?"

 and

 Subject: Specifying RRULE UNTIL parameter for events using DATE or
floating times
 From owner-ietf-calendar Fri Oct  5 18:05:04 2001
)

---

From: "ME" <[email-masked]>
Date: Tue, 4 Apr 2006 00:27:38 -0700 (PDT)

I was sent a private reply on this issue of making it possible for UNTIL
to include floating time for date-time when valid ";TZID=" are included
with DTSTART for events.

A summary for the reply was that there is a problem with using floating
times as a date-time in timezones that encuonter periods of Daylight
Saving Time:
1) What happens when a non-existent hour (clocks moving forward) happens
to be on any "UNTIL instance other than the first days? And how is this
considered?
2) What happens when an hour is duplicated, and there is effectively a
collision in the matching result-space? And how is this resolved?

First, I submit that government's choosing to change their UTC offset, and
BEGIN/END for DST creates greater risks for dropped events that are not
updated, than predictable periods of DST.

The burden of having events work properly across timezones falls to the
organizer to somehow have knowledge of a change in all attendees'
timezones, and for the organizer to ALSO have the most up-to-date legal
timezone data for the attendees region (or use of a shared "root"
authoritative timezone source) so that a new ICS extract can be sent to
all attendees who live in a timezones that change during the period of the
UNTIL.

Propagation of such data is overly-complicated, and a burden of knowning
about changes to attendee timezones is placed on the organizer, in making
new extracts for each timezone change.

(Realize that the US is changing its begin of DST to one month sooner in
2007-- better hope any organizers outside the US know about this and
update events to their US attendees for recurring events into 2007 that
may fall in the 3 week-difference window.)

Re-stated, the arguements for UNTIL needing to be in UTC should also apply
to DTSTART for the same reason:

1) It is possible (technically by RFC, but not legally, by government
Timezone) to manufacture a DTSTART that does not exist (during the hour
that is lost in DST) especially for events that include attendees in
different timezones that have DST start on different days or times or not
at all.
2) It is possible to also have ambiguity in setting a start date-time in
DTSTART that is in the "replayed" hour when clock are set back one hour
(especially when events include people from different timezones.)

What may be a valid DTSTART for my TIMEZONE may not be valid for yours,
and with timezones changing defintions, offset from UTC, or observation of
DST, we have complication.

Result? If UNTIL is broken with non-UTC times (like those with TZID), then
DTSTART is also broken with non-UTC times, and so is DTEND.

Solution?
A "hack" can be introducted into the RFC (like the "00:00:60" leap second
features, to have an hour "24:00:00 - "24:59:59" count for the replayed
hour and the skipped hour be invalid to clients.
(However, this creates other problems.)

Another solution?
(Ab)use of "DURATION" in addition to DTSTART and DTEND.
If DURATION is included with a DTSTART and DTEND, and (seconds)DURATION =
(seconds)(DTEND-DTSTART) then the length of the event is more important
than the end time, and when an hour is lost as clocks skip forward, the
real end of a DST border case will appear to legally end 1 hour later.
Also, when an hour is repeated, there is no ambiguity on whe the event
ends-- especially if the event include a duration i hours.
If DURATION is omitted while DTSTART and DTEND and included, then the
actual end time is more important that the duration. For cases where an
hour is lost, the event would end at the time specified, or if during an
illegal time, then the last legal time before the lost time. For cases
where clocks are set back, the real end time is the same, and the duration
of any DST event is shortened. For cases on the DST, duration can be
computed by the client.

This could be used with the above "24:00:00 - :24:59:59" system for DST
where we gain an hour too.

(It appears the person that contacted me with a response sent me a private
message, and I don't feel comfortable mentioning their name in public to
thank them for their thoughtful response. I am omitting their name for the
sake of privacy, but I am thanksing them anyway. Thanks!)

Thanks for your time, :-)
-ME

> 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."
UTC time."
includes ;TZID=
timezone issues, but can create issues with border cases for events that
happen in the early morning, or late evening in timezones that are
offset
"DURATION' properties MUST be present in the associated "VEVENT"
calendar component. If the alarm is specified for a to-do with a trigger
set relative to the END, then either the "DUE" property or the "DSTART"
and "DURATION' properties MUST be present in the