svn commit: r320242 - head/etc/ntp
Cy Schubert
Cy.Schubert at komquats.com
Fri Jun 23 02:12:21 UTC 2017
In message <2caa5927-9919-ce19-93f4-1005a5257295 at freebsd.org>, Allan Jude
write
s:
> On 2017-06-22 21:04, Cy Schubert wrote:
> > In message <1498161747.66489.10.camel at 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 at 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 at cschubert.com>
> > FreeBSD UNIX: <cy at 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 at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
More information about the svn-src-all
mailing list