From owner-svn-src-head@freebsd.org Fri Jun 23 02:00:03 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92856D99B9E; Fri, 23 Jun 2017 02:00:03 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 596C1732C5; Fri, 23 Jun 2017 02:00:03 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.10] (unknown [192.168.1.10]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 0A39F132BC; Fri, 23 Jun 2017 02:00:01 +0000 (UTC) Subject: Re: svn commit: r320242 - head/etc/ntp To: Cy Schubert , Ian Lepore Cc: Cy Schubert , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201706230104.v5N14e3e031473@slippy.cwsent.com> From: Allan Jude Message-ID: <2caa5927-9919-ce19-93f4-1005a5257295@freebsd.org> Date: Thu, 22 Jun 2017 21:59:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <201706230104.v5N14e3e031473@slippy.cwsent.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-CA Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 02:00:03 -0000 On 2017-06-22 21:04, Cy Schubert wrote: > In message <1498161747.66489.10.camel@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@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 > FreeBSD UNIX: 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