svn commit: r320242 - head/etc/ntp

Fri Jun 23 02:19:07 UTC 2017

In message <201706230210.v5N2At0l075844 at slippy.cwsent.com>, Cy Schubert 
writes:
> 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, 
                                                             since

The brain is faster than 
-- 
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 fingers.

> 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.
>