svn commit: r347488 - head/usr.sbin/ntp/ntpd

[Ian Lepore]

On Sat, 2019-05-11 at 14:22 +0000, Xin LI wrote:
> Author: delphij
> Date: Sat May 11 14:22:21 2019
> New Revision: 347488
> URL: https://svnweb.freebsd.org/changeset/base/347488
> 
> Log:
>   Update leap-seconds to leap-seconds.3757622400.
>   

For future reference:  it's a bit better to get this file from NIST [*]
than from USNO.  The USNO boilerplate is full of typos, and USNO
incorrectly adjusts the "last update date" metadata every time they
change the expiration date of the file.  That's not correct... as the
boilerplate itself states, that field is only supposed to be updated
when new leap seconds are added to the file.

[*] ftp://ftp.nist.gov/pub/time/leap-seconds.list

-- Ian

>   As per 
> https://datacenter.iers.org/data/latestVersion/16_BULLETIN_C16.txt:
>   
>        INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE
> (IERS)
>   
>   SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE
> REFERENCE
>   
>   SERVICE DE LA ROTATION TERRESTRE DE L'IERS
>   OBSERVATOIRE DE PARIS
>   61, Av. de l'Observatoire 75014 PARIS (France)
>   Tel.      : +33 1 40 51 23 35
>   e-mail    : services.iers at obspm.fr
>   http://hpiers.obspm.fr/eop-pc
>   
>                                                 Paris, 07 January
> 2019
>   
>                                                 Bulletin C 57
>   
>                                                 To authorities
> responsible
>                                                 for the measurement
> and
>                                                 distribution of time
>   
>                             INFORMATION ON UTC - TAI
>   
>    NO leap second will be introduced at the end of June 2019.
>    The difference between Coordinated Universal Time UTC and the
>    International Atomic Time TAI is :
>   
>        from 2017 January 1, 0h UTC, until further notice : UTC-TAI =
> -37 s
>   
>    Leap seconds can be introduced in UTC at the end of the months of
> December
> +#      a comment, which continues from that symbol until 
>    six months, either to announce a time step in UTC, or to confirm
> that there
>    will be no time step at the next possible date.
>   
>                                               Christian BIZOUARD
>                                               Director
>                                               Earth Orientation
> Center of IERS
>   					    Observatoire de Paris,
> France
>   
>   Requested by:	rgrimes
>   Obtained from:	
> ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.3757622400
>   MFC after:	3 days
> 
> Modified:
>   head/usr.sbin/ntp/ntpd/leap-seconds
> 
> Modified: head/usr.sbin/ntp/ntpd/leap-seconds
> =====================================================================
> =========
> --- head/usr.sbin/ntp/ntpd/leap-seconds	Sat May 11 10:16:43
> 2019	(r347487)
> +++ head/usr.sbin/ntp/ntpd/leap-seconds	Sat May 11 14:22:21
> 2019	(r347488)
> @@ -1,10 +1,10 @@
>  #
>  #	In the following text, the symbol '#' introduces
> -#	a comment, which continues from that symbol until
> +#	a comment, which continues from that symbol until 
>  #	the end of the line. A plain comment line has a
>  #	whitespace character following the comment indicator.
> -#	There are also special comment lines defined below.
> -#	A special comment will always have a non-whitespace
> +#	There are also special comment lines defined below. 
> +#	A special comment will always have a non-whitespace 
>  #	character in column 2.
>  #
>  #	A blank line should be ignored.
> @@ -15,22 +15,17 @@
>  #	are transmitted by almost all time services.
>  #
>  #	The first column shows an epoch as a number of seconds
> -#	since 1 January 1900, 00:00:00 (1900.0 is also used to
> -#	indicate the same epoch.) Both of these time stamp formats
> -#	ignore the complexities of the time scales that were
> -#	used before the current definition of UTC at the start
> -#	of 1972. (See note 3 below.)
> -#	The second column shows the number of seconds that
> -#	must be added to UTC to compute TAI for any timestamp
> -#	at or after that epoch. The value on each line is
> -#	valid from the indicated initial instant until the
> -#	epoch given on the next one or indefinitely into the
> -#	future if there is no next line.
> +#	since 1900.0 and the second column shows the number of
> +#	seconds that must be added to UTC to compute TAI for
> +#	any timestamp at or after that epoch. The value on 
> +#	each line is valid from the indicated initial instant
> +#	until the epoch given on the next one or indefinitely 
> +#	into the future if there is no next line.
>  #	(The comment on each line shows the representation of
> -#	the corresponding initial epoch in the usual
> +#	the corresponding initial epoch in the usual 
>  #	day-month-year format. The epoch always begins at
>  #	00:00:00 UTC on the indicated day. See Note 5 below.)
> -#
> +#	
>  #	Important notes:
>  #
>  #	1. Coordinated Universal Time (UTC) is often referred to
> @@ -38,7 +33,7 @@
>  #	longer used, and the use of GMT to designate UTC is
>  #	discouraged.
>  #
> -#	2. The UTC time scale is realized by many national
> +#	2. The UTC time scale is realized by many national 
>  #	laboratories and timing centers. Each laboratory
>  #	identifies its realization with its name: Thus
>  #	UTC(NIST), UTC(USNO), etc. The differences among
> @@ -47,12 +42,12 @@
>  #	and can be ignored for many purposes. These differences
>  #	are tabulated in Circular T, which is published monthly
>  #	by the International Bureau of Weights and Measures
> -#	(BIPM). See www.bipm.org for more information.
> +#	(BIPM). See www.bipm.fr for more information.
>  #
> -#	3. The current definition of the relationship between UTC
> -#	and TAI dates from 1 January 1972. A number of different
> -#	time scales were in use before that epoch, and it can be
> -#	quite difficult to compute precise timestamps and time
> +#	3. The current defintion of the relationship between UTC 
> +#	and TAI dates from 1 January 1972. A number of different 
> +#	time scales were in use before than epoch, and it can be 
> +#	quite difficult to compute precise timestamps and time 
>  #	intervals in those "prehistoric" days. For more information,
>  #	consult:
>  #
> @@ -63,34 +58,36 @@
>  #		of Time," Proc. of the IEEE, Vol. 79, pp. 894-905,
>  #		July, 1991.
>  #
> -#	4. The decision to insert a leap second into UTC is currently
> -#	the responsibility of the International Earth Rotation and
> -#	Reference Systems Service. (The name was changed from the
> -#	International Earth Rotation Service, but the acronym IERS
> -#	is still used.)
> +#	4.  The insertion of leap seconds into UTC is currently the
> +#	responsibility of the International Earth Rotation Service,
> +#	which is located at the Paris Observatory: 
>  #
> -#	Leap seconds are announced by the IERS in its Bulletin C.
> +#	Central Bureau of IERS
> +#	61, Avenue de l'Observatoire
> +#	75014 Paris, France.
>  #
> -#	See www.iers.org for more details.
> +#	Leap seconds are announced by the IERS in its Bulletin C
>  #
> -#	Every national laboratory and timing center uses the
> -#	data from the BIPM and the IERS to construct UTC(lab),
> -#	their local realization of UTC.
> +#	See hpiers.obspm.fr or www.iers.org for more details.
>  #
> +#	All national laboratories and timing centers use the
> +#	data from the BIPM and the IERS to construct their
> +#	local realizations of UTC.
> +#
>  #	Although the definition also includes the possibility
> -#	of dropping seconds ("negative" leap seconds), this has
> -#	never been done and is unlikely to be necessary in the
> +#	of dropping seconds ("negative" leap seconds), this has 
> +#	never been done and is unlikely to be necessary in the 
>  #	foreseeable future.
>  #
>  #	5. If your system keeps time as the number of seconds since
>  #	some epoch (e.g., NTP timestamps), then the algorithm for
>  #	assigning a UTC time stamp to an event that happens during a
> positive
> -#	leap second is not well defined. The official name of that leap
> -#	second is 23:59:60, but there is no way of representing that
> time
> -#	in these systems.
> -#	Many systems of this type effectively stop the system clock for
> -#	one second during the leap second and use a time that is
> equivalent
> -#	to 23:59:59 UTC twice. For these systems, the corresponding TAI
> +#	leap second is not well defined. The official name of that
> leap 
> +#	second is 23:59:60, but there is no way of representing that
> time 
> +#	in these systems. 
> +#	Many systems of this type effectively stop the system clock
> for 
> +#	one second during the leap second and use a time that is
> equivalent 
> +#	to 23:59:59 UTC twice. For these systems, the corresponding
> TAI 
>  #	timestamp would be obtained by advancing to the next entry in
> the
>  #	following table when the time equivalent to 23:59:59 UTC
>  #	is used for the second time. Thus the leap second which
> @@ -105,7 +102,7 @@
>  #
>  #	If your system realizes the leap second by repeating 00:00:00
> UTC twice
>  #	(this is possible but not usual), then the advance to the next
> entry
> -#	in the table must occur the second time that a time equivalent
> to
> +#	in the table must occur the second time that a time equivlent
> to 
>  #	00:00:00 UTC is used. Thus, using the same example as above:
>  #
>  #	...
> @@ -115,94 +112,66 @@
>  #	...
>  #
>  #	in both cases the use of timestamps based on TAI produces a
> smooth
> -#	time scale with no discontinuity in the time interval. However,
> -#	although the long-term behavior of the time scale is correct in
> both
> -#	methods, the second method is technically not correct because
> it adds
> -#	the extra second to the wrong day.
> +#	time scale with no discontinuity in the time interval.
>  #
> -#	This complexity would not be needed for negative leap seconds
> (if they
> -#	are ever used). The UTC time would skip 23:59:59 and advance
> from
> -#	23:59:58 to 00:00:00 in that case. The TAI offset would
> decrease by
> -#	1 second at the same instant. This is a much easier situation
> to deal
> -#	with, since the difficulty of unambiguously representing the
> epoch
> +#	This complexity would not be needed for negative leap seconds
> (if they 
> +#	are ever used). The UTC time would skip 23:59:59 and advance
> from 
> +#	23:59:58 to 00:00:00 in that case.  The TAI offset would
> decrease by 
> +#	1 second at the same instant.  This is a much easier situation
> to deal 
> +#	with, since the difficulty of unambiguously representing the
> epoch 
>  #	during the leap second does not arise.
>  #
> -#	Some systems implement leap seconds by amortizing the leap
> second
> -#	over the last few minutes of the day. The frequency of the
> local
> -#	clock is decreased (or increased) to realize the positive (or
> -#	negative) leap second. This method removes the time step
> described
> -#	above. Although the long-term behavior of the time scale is
> correct
> -#	in this case, this method introduces an error during the
> adjustment
> -#	period both in time and in frequency with respect to the
> official
> -#	definition of UTC.
> -#
>  #	Questions or comments to:
> -#		Judah Levine
> -#		Time and Frequency Division
> -#		NIST
> -#		Boulder, Colorado
> -#		Judah.Levine at nist.gov
> +#		Jeff Prillaman
> +#		Time Service Department
> +#		US Naval Observatory
> +#		Washington, DC
> +#		jeff.k.prillaman at navy.mil
>  #
> -#	Last Update of leap second values:   8 July 2016
> +#	Last Update of leap second values:  28 Jan 2019
>  #
> -#	The following line shows this last update date in NTP timestamp
> +#	The following line shows this last update date in NTP
> timestamp 
>  #	format. This is the date on which the most recent change to
>  #	the leap second data was added to the file. This line can
> -#	be identified by the unique pair of characters in the first two
> +#	be identified by the unique pair of characters in the first
> two 
>  #	columns as shown below.
>  #
> -#$	 3676924800
> +#$	3757622400
>  #
> -#	The NTP timestamps are in units of seconds since the NTP epoch,
> -#	which is 1 January 1900, 00:00:00. The Modified Julian Day
> number
> -#	corresponding to the NTP time stamp, X, can be computed as
> -#
> -#	X/86400 + 15020
> -#
> -#	where the first term converts seconds to days and the second
> -#	term adds the MJD corresponding to the time origin defined
> above.
> -#	The integer portion of the result is the integer MJD for that
> -#	day, and any remainder is the time of day, expressed as the
> -#	fraction of the day since 0 hours UTC. The conversion from day
> -#	fraction to seconds or to hours, minutes, and seconds may
> involve
> -#	rounding or truncation, depending on the method used in the
> -#	computation.
> -#
> -#	The data in this file will be updated periodically as new leap
> +#	The data in this file will be updated periodically as new leap 
>  #	seconds are announced. In addition to being entered on the line
> -#	above, the update time (in NTP format) will be added to the
> basic
> +#	above, the update time (in NTP format) will be added to the
> basic 
>  #	file name leap-seconds to form the name leap-seconds.<NTP
> TIME>.
> -#	In addition, the generic name leap-seconds.list will always
> point to
> +#	In addition, the generic name leap-seconds.list will always
> point to 
>  #	the most recent version of the file.
>  #
>  #	This update procedure will be performed only when a new leap
> second
> -#	is announced.
> +#	is announced. 
>  #
>  #	The following entry specifies the expiration date of the data
> -#	in this file in units of seconds since the origin at the
> instant
> -#	1 January 1900, 00:00:00. This expiration date will be changed
> -#	at least twice per year whether or not a new leap second is
> -#	announced. These semi-annual changes will be made no later
> -#	than 1 June and 1 December of each year to indicate what
> -#	action (if any) is to be taken on 30 June and 31 December,
> +#	in this file in units of seconds since 1900.0.  This expiration
> date 
> +#	will be changed at least twice per year whether or not a new
> leap 
> +#	second is announced. These semi-annual changes will be made no
> +#	later than 1 June and 1 December of each year to indicate what
> +#	action (if any) is to be taken on 30 June and 31 December, 
>  #	respectively. (These are the customary effective dates for new
>  #	leap seconds.) This expiration date will be identified by a
>  #	unique pair of characters in columns 1 and 2 as shown below.
> -#	In the unlikely event that a leap second is announced with an
> +#	In the unlikely event that a leap second is announced with an 
>  #	effective date other than 30 June or 31 December, then this
>  #	file will be edited to include that leap second as soon as it
> is
>  #	announced or at least one month before the effective date
> -#	(whichever is later).
> -#	If an announcement by the IERS specifies that no leap second is
> -#	scheduled, then only the expiration date of the file will
> +#	(whichever is later). 
> +#	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
> +#	current -- the update time stamp, the data and the name of the
> file 
>  #	will not change.
>  #
> -#	Updated through IERS Bulletin C53
> -#	File expires on:  28 December 2017
> +#	Updated through IERS Bulletin C 57
> +#	File expires on:   1 Dec 2019
>  #
> -#@	3723408000
> +#@	3784147200
>  #
>  2272060800	10	# 1 Jan 1972
>  2287785600	11	# 1 Jul 1972
> @@ -236,15 +205,16 @@
>  #	the following special comment contains the
>  #	hash value of the data in this file computed
>  #	use the secure hash algorithm as specified
> -#	by FIPS 180-1. See the files in ~/pub/sha for
> +#	by FIPS 180-1. See the files in ~/sha for
>  #	the details of how this hash value is
>  #	computed. Note that the hash computation
>  #	ignores comments and whitespace characters
>  #	in data lines. It includes the NTP values
> -#	of both the last modification time and the
> +#	of both the last modification time and the 
>  #	expiration time of the file, but not the
>  #	white space on those lines.
>  #	the hash line is also ignored in the
>  #	computation.
>  #
> -#h	62cf8c5d 8bbb6dcc c61e3b56 c308343 869bb80d
> +#h	630ac741 2fffdd6b 858a7d1d 31d4802f 6382e10c
> +#
>