svn commit: r347488 - head/usr.sbin/ntp/ntpd
Rodney W. Grimes
freebsd at gndrsh.dnsmgr.net
Sat May 11 16:37:16 UTC 2019
> 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.
I would be very happy if that information would end up in the
top of, or next to the leap-seconds file so that it was followed
in the future, rather than being folk lore.
Thanks,
Rod
> [*] 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
> > +#
> >
>
>
>
--
Rod Grimes rgrimes at freebsd.org
More information about the svn-src-head
mailing list