Date: Thu, 22 Jun 2017 19:10:55 -0700 From: Cy Schubert <Cy.Schubert@komquats.com> To: Allan Jude <allanjude@freebsd.org> Cc: Cy Schubert <Cy.Schubert@komquats.com>, Ian Lepore <ian@freebsd.org>, Cy Schubert <cy@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r320242 - head/etc/ntp Message-ID: <201706230210.v5N2At0l075844@slippy.cwsent.com> In-Reply-To: Message from Allan Jude <allanjude@freebsd.org> of "Thu, 22 Jun 2017 21:59:57 -0400." <2caa5927-9919-ce19-93f4-1005a5257295@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <2caa5927-9919-ce19-93f4-1005a5257295@freebsd.org>, Allan Jude write s: > On 2017-06-22 21:04, Cy Schubert wrote: > > In message <1498161747.66489.10.camel@freebsd.org>, Ian Lepore writes: > >> On Thu, 2017-06-22 at 19:25 +0000, Cy Schubert wrote: > >>> Author: cy > >>> Date: Thu Jun 22 19:25:17 2017 > >>> New Revision: 320242 > >>> URL: https://svnweb.freebsd.org/changeset/base/320242 > >>> > >>> Log: > >>>  Update leap-seconds to leap-seconds.3701462400. > >>>  > >>> > >>> Modified: head/etc/ntp/leap-seconds > >>> ===================================================================== > >>> ========= > >>> --- head/etc/ntp/leap-seconds Thu Jun 22 18:40:34 2017 > >>> (r320241) > >>> +++ head/etc/ntp/leap-seconds Thu Jun 22 19:25:17 2017 > >>> (r320242) > >>> @@ -128,7 +128,7 @@ > >>>  # Washington, DC > >>>  # jeffrey.prillaman@usno.navy.mil > >>>  # > >>> -# Last Update of leap second values:   6 Jul 2016 > >>> +# Last Update of leap second values:  18 Apr 2017 > >>>  # > >>  # The following line shows this last update date in NTP > >>> timestamp > >>>  # format. This is the date on which the most recent change to > >>> @@ -136,7 +136,7 @@ > >>>  # be identified by the unique pair of characters in the first > >>> two > >>>  # columns as shown below. > >>>  # > >>> -#$  3676752000 > >>> +#$  3701462400 > >>>  # > >> > >> Where did this leapfile come from?  The last update of leap second > >> values is supposed to change only when the actual list of offsets > >> changes, not when the file is updated to just change an expiration > >> date.  This is actually very explicitly documented in the file itself, > >> just a few lines down from this change: > > > > The source of the leapfile is in the commit message. Here it is again: > > > > Obtained from: ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.3701462400 > > > >> > >>  If an announcement by the IERS specifies that no leap second is > >>  scheduled, then only the expiration date of the file will > >>  be advanced to show that the information in the file is still > >>  current -- the update time stamp, the data and the name of the file > >>  will not change. > >> > >> > >>> -# File expires on:  1 Jun 2017 > >>> +# Updated through IERS Bulletin C 53 > >>> +# File expires on:  1 Dec 2017 > >>>  # > >>> -#@ 3705264000 > >>> +#@ 3721075200 > >>>  # > >> > >> This expiration is wrong too, dangerously so IMO.  The data in the file > >> is good through 12-31-2017-23:59:59, although historical practice has > >> been to make the file expire a couple days before that.  Making it > >> expire 31 days early is about the worst possible choice... some systems > >> for notifying clients/consumers of an impending leap second (or the > >> lack thereof) only do so during the last month before the leap > >> opportunity -- this has the file expire just at the point such software > >> would consider it authoratative for dissemination. > > > > My guess is that USNO may have had reason to do so. I'll keep an eye on > > their next release of the file. > >  > >> > >> I will note however, unlike the update date, there is no formal written > >> description of how expiration date is determined, so the previous > >> paragraph is just my opinion and experience working in the timing > >> field. > >> > >> A leapfile without these problems can be found at > >> > >>   ftp://time.nist.gov/pub/leap-seconds.list > > > > We can use that instead. Attached is the diff between the USNO and NIST > > versions of the file. > > > > One would think that two groups within the US Government might be able to > > produce a consistent leapfile. I suspect the real reason is that the USNO > > might have a different bureaucratic process than the NIST does. > > > >> > >> > >> -- Ian > >> > >>>  2272060800 10 # 1 Jan 1972 > >>>  2287785600 11 # 1 Jul 1972 > >>> @@ -216,5 +216,5 @@ > >>>  # the hash line is also ignored in the > >>>  # computation. > >>>  # > >>> -#h 63f8fea8 587c099d abcf130a ad525eae 3e105052 > >>> +#h 3f004255 91f969f7 252361e5 27aa6754 eb6b7c72 > >>>  # > >>> > >> > > > > I'll update to the NIST version of the file. > > > > > > > > > > > > > > Cheers, > > Cy Schubert <Cy.Schubert@cschubert.com> > > FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org > > > > The need of the many outweighs the greed of the few. > > > > The NIST version does seem to have a number of improvements, like > corrected typos etc, but: > > -# Last Update of leap second values: 18 Apr 2017 > +# Last Update of leap second values: 8 July 2016 > > The USNO one seems newer. A bit strange. That was Ian's issue. I think the following explanation makes sense: The leap second itself wasn't updated in the NIST version file cine July 8, 2016, even though the file itself had been updated since then. I think USNO sees that date as the date the file itself was updated, not the leap second value, like NIST would appear it does. It sees like a fair hypothesis. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201706230210.v5N2At0l075844>