From owner-svn-src-head@freebsd.org Thu Jun 22 20:02:31 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 0A9C1D93846 for ; Thu, 22 Jun 2017 20:02:31 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 E1F0537E9 for ; Thu, 22 Jun 2017 20:02:30 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ba09caa3-5785-11e7-8dc9-a95799a96e8f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id ba09caa3-5785-11e7-8dc9-a95799a96e8f; Thu, 22 Jun 2017 20:02:32 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v5MK2RmQ008821; Thu, 22 Jun 2017 14:02:28 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1498161747.66489.10.camel@freebsd.org> Subject: Re: svn commit: r320242 - head/etc/ntp From: Ian Lepore To: Cy Schubert , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Thu, 22 Jun 2017 14:02:27 -0600 In-Reply-To: <201706221925.v5MJPHPa086049@repo.freebsd.org> References: <201706221925.v5MJPHPa086049@repo.freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 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: Thu, 22 Jun 2017 20:02:31 -0000 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:   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 >  # >