svn commit: r320242 - head/etc/ntp

[Ian Lepore]

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:

  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.  

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


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