Re: [Tzdist-bis] Leap Second Support Interval Field Request

Re: [Tzdist-bis] Leap Second Support Interval Field Request - RFC8536

Arthur David Olson <arthurdavidolson@gmail.com> Fri, 06 December 2019 05:10 UTC

MIME-Version: 1.0
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com> <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
In-Reply-To: <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
From: Arthur David Olson <arthurdavidolson@gmail.com>
Date: Fri, 06 Dec 2019 00:09:46 -0500
Message-ID: <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Michael Veth <michael.veth@vethresearch.com>, IESG <iesg@ietf.org>, Howard Hinnant <howard.hinnant@gmail.com>, Don Venable <donald.venable@vethresearch.com>, Time Zone Mailing List <tz@iana.org>, Extensions to Time Zone Data Distribution Service <tzdist-bis@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a50e530599020e7a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tzdist-bis/hRhuRI8IwRDT8CQ-QRqj2MbbOWE>
Subject: Re: [Tzdist-bis] Leap Second Support Interval Field Request - RFC8536
Precedence: list

One odd possibility below.

    @dashdashado

Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28
                        0       -       POST

On Thu, Dec 5, 2019 at 11:34 PM Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 12/4/19 1:04 PM, Michael Veth wrote:
>
> > The NIST leapsecond bulletin includes an expiration time which serves to
> > indicate the maximum validity interval for use of UTC time.  In order to
> > safely use UTC timestamps, the user needs to be aware of this maximum
> > validity time or they could be unknowingly introducing timing errors.
> >
> > I was not able to find this field in the TZif (Feb 19) ICD.  Would it be
> > possible to add a field to the TZdb that would represent this expiration
> > time?
>
> The TZif file format does provide for truncated files (see Internet RFC
> 8536 section 5.1), and one can generate files truncated to the current
> UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this:
>
> zic -r /@1593302427 -L leapseconds tzdata.zi
>
> However, it's awkward that one must count the number of seconds since
> 1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the
> numeric timestamp (1593302427 in this case) to pass to zic. We could add
> support to zic to do this sort of thing in a more-natural way.
>
> A downside of the abovementioned approach is that it generates a TZif
> file that omits all DST and time zone transitions after the UTC
> expiration time. We could change the TZif format to represent UTC
> expiration time separately from the truncation time. One possibility
> would be to append a leap-second record with an "occur" value equal to
> the expiration time and a "corr" value equal to the previous record's
> "corr" value. Strictly speaking this would violate RFC 8536 section 3.2
> "leap-second records" - though I doubt whether many clients would care -
> and so I suppose we'd need to increment the TZif format version number
> from 3 to 4. On the other hand, any files generated by this method would
> continue to be "incorrect" in that they'd continue to predict timestamps
> past the maximum leap second validity, so perhaps it wouldn't be worth
> going to all this work to generate "incorrect" files.
>
> I'll cc this to tz@iana.org and tzdist-bis@ietf.org to see whether
> anybody there cares to comment.
>

Re: [Tzdist-bis] Leap Second Support Interval Fie… Paul Eggert
Re: [Tzdist-bis] Leap Second Support Interval Fie… Arthur David Olson
Re: [Tzdist-bis] [tz] Leap Second Support Interva… Michael H Deckers
Re: [Tzdist-bis] Leap Second Support Interval Fie… Paul Eggert
Re: [Tzdist-bis] Leap Second Support Interval Fie… Michael H Deckers
Re: [Tzdist-bis] Leap Second Support Interval Fie… Paul Eggert