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

["ME" <dugan@xxxxxxxxxxxx>]

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

ME said:
>
> 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" <lennox@xxxxxxxxxxxxxxx>
>     "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 <lennox@xxxxxxxxxxxxxxx>
> "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
> )
>
>