Date: Thu, 22 Jun 2017 14:02:27 -0600 From: Ian Lepore <ian@freebsd.org> To: Cy Schubert <cy@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r320242 - head/etc/ntp Message-ID: <1498161747.66489.10.camel@freebsd.org> In-Reply-To: <201706221925.v5MJPHPa086049@repo.freebsd.org> References: <201706221925.v5MJPHPa086049@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > # >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1498161747.66489.10.camel>