On 2017-06-22 21:04, Cy Schubert wrote:
> In message <1498161747.66489.10.ca...@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.prilla...@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.schub...@cschubert.com>
> FreeBSD UNIX:  <c...@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.

-- 
Allan Jude
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to