svn commit: r320242 - head/etc/ntp

[Ian Lepore]

On Thu, 2017-06-22 at 21:59 -0400, Allan Jude wrote:
> 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.3701
> > 462400
> > 
> > > 
> > > 
> > > Â  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 the main point of my mail (with the expiration date being a
secondary point).  The NIST file's date is correct according to the
rules for changing it, which appear in the paragraph right after the
date itself.  USNO for some reason is updating this value when they
extend the expiration date, and that's not how it's supposed to work.

If USNO wants to document when they touch the file at all, they can do
so by inserting freeform comments, but not by manipulating the "Last
update of values" metadata field that begins with '#$'.

-- Ian