[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
UNTIL as a "floating" date-time as well as UTC date-time + Unrelated RFC Typo/Bug
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
)