Subject: Re: [Tzdist] Ticket #15

From: Daniel Migault <[email-masked]>
Date: Thu, 23 Oct 2014 22:26:43 +0200

Dear Friends and Colleagues,

v2 of the drat addresses this issue with the text below. Before we close
this issue, we would like to know whether the text of v2 has reached
consensus.

BR,
Daniel

Section 3.4 Truncating Time Zones
      [...]

   When truncating the end of a "VTIMEZONE" component, the server MUST
   include a "TZUNTIL" iCalendar property (Section 8.1
<http://tools.ietf.org/html/draft-ietf-tzdist-service-02#section-8.1>)
in the
   "VTIMEZONE" component to indicate the end point of the truncation
   range.

8.1. Time Zone Upper Bound

   Property Name:  TZUNTIL
   Purpose:  This property specifies an upper bound for the validity
of data within a "VTIMEZONE" component.
   Value Type:  DATE-TIME
   Property Parameters:  IANA and non-standard property parameters can
be specified on this property.
   Conformance:  This property can be specified zero or one time
within "VTIMEZONE" calendar components.
   Description:  The value MUST be specified in the UTC time format.

   Time zone data in a "VTIMEZONE" component might cover only a fixed
period of time. The start of such a period is clearly indicated by the
earliest observance defined by the "STANDARD" and "DAYLIGHT"
sub-components.  However, [RFC5545] does not define a way to indicate
an upper bound on the validity of the time zone data, which cannot be
simply derived from the observance with the latest onset time.  This
specification introduces the "TZUNTIL" property for that purpose.  It
specifies an "inclusive" UTC date time value that indicates the last
time at which the time zone data is to be considered valid.  For
example, a time zone based on astronomical observations might have
well defined values up to only the year 2025.  In that case, the
"TZUNTIL" value would match the last accurately known observance
transition in that year.

      This property is also used by time zone data distribution
servers to indicate the truncation range end point of time zone data
(as described in Section 3.4).

   Format Definition:  This property is defined by the following notation:

   tzuntil      = "TZUNTIL" tzuntilparam ":" date-time CRLF
   tzuntilparam = *(";" other-param)

   Example:  The following is an example of this property:

   TZUNTIL:20371231T115959Z

On Sun, Aug 31, 2014 at 2:50 AM, Paul Eggert <[email-masked]> wrote:

> Daniel Migault wrote:
>
>  I guess the question is do we agree that it should be handled with a
>> VTIMEZONE extension and not by the time zone distribution protocol?
>>
>
> I wasn't proposing to wait until a VTIMEZONE extension could be
> standardized.  I was proposing to use unextended, ordinary VTIMEZONE. That
> is, tzdist would use ordinary VTIMEZONE format, and would specify the
> interpretation or formatting of certain information that RFC 5545 leaves
> unspecified.  It could be thought of as a VTIMEZONE profile, I suppose.
> The draft already imposes restrictions on tzdist-based VTIMEZONE data
> (e.g., in Section 3.4) and it could easily impose a few more.
>
> If VTIMEZONE is extended in the future I suppose that would be nice too,
> but why wait?
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Paul Eggert <[email-masked]>
Date: Thu, 23 Oct 2014 18:48:28 -0700

Daniel Migault wrote:
> For
 > ...

This suggests that a TZUNTIL value of T would equal the last observed transition 
time T in that year.  But TZUNTIL times are inclusive at the end whereas 
transition times are inclusive at the start, so the two T values should not be 
equal; the latter should be strictly less than the latter.

To help clear this up, I suggest rewording the above as follows:

...
Example: Suppose a time zone based on astronomical observations has well-defined 
onset times through the year 2025, but the first onset in 2026 is currently 
known only approximately.  In that case, the "TZUNTIL" property could be 
specified as follows:

   TZUNTIL:20251231T115959Z