Author: cy Date: Fri Jan 1 11:57:32 2016 New Revision: 293037 URL: https://svnweb.freebsd.org/changeset/base/293037
Log: Update leap-seconds to latest. This will satisfy the ntpd leap-second version check. Obtained from: ftp://tycho.usno.navy.mil/pub/ntp/. See also: http://www.iers.org/SharedDocs/News/EN/BulletinC.html Modified: head/etc/ntp/leap-seconds Modified: head/etc/ntp/leap-seconds ============================================================================== --- head/etc/ntp/leap-seconds Fri Jan 1 11:19:32 2016 (r293036) +++ head/etc/ntp/leap-seconds Fri Jan 1 11:57:32 2016 (r293037) @@ -1,119 +1,221 @@ # # $FreeBSD$ # -# ATOMIC TIME. -# The Coordinated Universal Time (UTC) is the reference time scale derived -# from The "Temps Atomique International" (TAI) calculated by the Bureau -# International des Poids et Mesures (BIPM) using a worldwide network of atomic -# clocks. UTC differs from TAI by an integer number of seconds; it is the basis -# of all activities in the world. -# -# -# ASTRONOMICAL TIME (UT1) is the time scale based on the rate of rotation of the earth. -# It is now mainly derived from Very Long Baseline Interferometry (VLBI). The various -# irregular fluctuations progressively detected in the rotation rate of the Earth lead -# in 1972 to the replacement of UT1 by UTC as the reference time scale. -# -# -# LEAP SECOND -# Atomic clocks are more stable than the rate of the earth rotatiob since the later -# undergoes a full range of geophysical perturbations at various time scales (lunisolar -# and core-mantle torques,atmospheric and oceanic effetcs, ...) -# Leap seconds are needed to keep the two time scales in agreement, i.e. UT1-UTC smaller -# than 0.9 second. So, when necessary a "leap second" is introduced in UTC. -# Since the adoption of this system in 1972 it has been necessary to add 26 seconds to UTC, -# firstly due to the initial choice of the value of the second (1/86400 mean solar day of -# the year 1820) and secondly to the general slowing down of the Earth's rotation. It is -# theorically possible to have a negative leap second (a second removed from UTC), but so far, -# all leap seconds have been positive (a second has been added to UTC). Based on what we know about the earth's rotation, -# it is unlikely that we will ever have a negative leap second. -# -# -# HISTORY -# The first leap second was added on June 30, 1972. Until 2000, it was necessary in average to add a leap second at a rate -# of 1 to 2 years. Since 2000, due to the fact that the earth rate of rotation is accelerating, leap seconds are introduced -# with an average frequency of 3 to 4 years. -# -# -# RESPONSABILITY OF THE DECISION TO INTRODUCE A LEAP SECOND IN UTC -# The decision to introduce a leap second in UTC is the responsibility of the Earth Orientation Center of -# the International Earth Rotation and reference System Service (IERS). This center is located at Paris -# Observatory. According to international agreements, leap second date have to occur at fixed date : -# first preference is given to the end of December and June, and second preference at the end of March -# and September. Since the system was introduced in 1972, only dates in June and December were used. -# -# Questions or comments to: -# Daniel Gambis, daniel.gam...@obspm.fr -# Christian Bizouard: christian.bizou...@obspm.fr -# Earth orientation Center of the IERS -# Paris Observatory, France -# -# -# -# VALIDITY OF THE FILE -# It is important to express the validity of the file. These next two dates are -# given in units of seconds since 1900.0. -# -# 1) Last update of the file. -# -# Updated through IERS Bulletin C (ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat) -# -# The following line shows the last update of this file in NTP timestamp: -# -#$ 3645216000 -# -# 2) Expiration date of the file given on a semi-annual basis: last June or last December -# -# File expires on 28 December 2015 -# -# Expire date in NTP timestamp: -# -#@ 3660249600 -# -# -# LIST OF LEAP SECONDS -# NTP timestamp (X parameter) is the number of seconds since 1900.0 -# -# MJD: The Modified Julian Day number. MJD = X/86400 + 15020 -# -# DTAI: The difference DTAI= TAI-UTC in units of seconds -# It is the quantity to add to UTC to get the time in TAI -# -# Day Month Year : epoch in clear -# -#NTP Time DTAI Day Month Year -# -2272060800 10 # 1 Jan 1972 -2287785600 11 # 1 Jul 1972 -2303683200 12 # 1 Jan 1973 -2335219200 13 # 1 Jan 1974 -2366755200 14 # 1 Jan 1975 -2398291200 15 # 1 Jan 1976 -2429913600 16 # 1 Jan 1977 -2461449600 17 # 1 Jan 1978 -2492985600 18 # 1 Jan 1979 -2524521600 19 # 1 Jan 1980 -2571782400 20 # 1 Jul 1981 -2603318400 21 # 1 Jul 1982 -2634854400 22 # 1 Jul 1983 -2698012800 23 # 1 Jul 1985 -2776982400 24 # 1 Jan 1988 -2840140800 25 # 1 Jan 1990 -2871676800 26 # 1 Jan 1991 -2918937600 27 # 1 Jul 1992 -2950473600 28 # 1 Jul 1993 -2982009600 29 # 1 Jul 1994 -3029443200 30 # 1 Jan 1996 -3076704000 31 # 1 Jul 1997 -3124137600 32 # 1 Jan 1999 -3345062400 33 # 1 Jan 2006 -3439756800 34 # 1 Jan 2009 -3550089600 35 # 1 Jul 2012 -3644697600 36 # 1 Jul 2015 -# -# In order to verify the integrity of this file, a hash code -# has been generated. For more information how to use -# this hash code, please consult the README file under the -# 'sha' repertory. +# In the following text, the symbol '#' introduces +# 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 +# character in column 2. +# +# A blank line should be ignored. +# +# The following table shows the corrections that must +# be applied to compute International Atomic Time (TAI) +# from the Coordinated Universal Time (UTC) values that +# are transmitted by almost all time services. +# +# The first column shows an epoch as a number of seconds +# 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 +# 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 +# as Greenwich Mean Time (GMT). The GMT time scale is no +# longer used, and the use of GMT to designate UTC is +# discouraged. +# +# 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 +# these different realizations are typically on the +# order of a few nanoseconds (i.e., 0.000 000 00x s) +# 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.fr for more information. +# +# 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: +# +# The Explanatory Supplement to the Astronomical +# Ephemeris. +# or +# Terry Quinn, "The BIPM and the Accurate Measurement +# of Time," Proc. of the IEEE, Vol. 79, pp. 894-905, +# July, 1991. +# +# 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: +# +# Central Bureau of IERS +# 61, Avenue de l'Observatoire +# 75014 Paris, France. +# +# Leap seconds are announced by the IERS in its Bulletin C +# +# 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 +# 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 +# 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 +# occurred on 30 June 1972 at 23:59:59 UTC would have TAI +# timestamps computed as follows: +# +# ... +# 30 June 1972 23:59:59 (2287785599, first time): TAI= UTC + 10 seconds +# 30 June 1972 23:59:60 (2287785599,second time): TAI= UTC + 11 seconds +# 1 July 1972 00:00:00 (2287785600) TAI= UTC + 11 seconds +# ... +# +# 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 equivlent to +# 00:00:00 UTC is used. Thus, using the same example as above: +# +# ... +# 30 June 1972 23:59:59 (2287785599): TAI= UTC + 10 seconds +# 30 June 1972 23:59:60 (2287785600, first time): TAI= UTC + 10 seconds +# 1 July 1972 00:00:00 (2287785600,second time): TAI= UTC + 11 seconds +# ... +# +# in both cases the use of timestamps based on TAI produces a smooth +# 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 +# during the leap second does not arise. +# +# Questions or comments to: +# Jeff Prillaman +# Time Service Department +# US Naval Observatory +# Washington, DC +# jeffrey.prilla...@usno.navy.mil +# +# Last Update of leap second values: 31 Dec 2015 +# +# 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 +# columns as shown below. +# +#$ 3660508800 +# +# 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 +# file name leap-seconds to form the name leap-seconds.<NTP TIME>. +# 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. +# +# The following entry specifies the expiration date of the data +# 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 +# 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 +# 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. +# +# Updated through IERS Bulletin C 50 +# File expires on: 1 Jun 2016 +# +#@ 3673728000 +# +2272060800 10 # 1 Jan 1972 +2287785600 11 # 1 Jul 1972 +2303683200 12 # 1 Jan 1973 +2335219200 13 # 1 Jan 1974 +2366755200 14 # 1 Jan 1975 +2398291200 15 # 1 Jan 1976 +2429913600 16 # 1 Jan 1977 +2461449600 17 # 1 Jan 1978 +2492985600 18 # 1 Jan 1979 +2524521600 19 # 1 Jan 1980 +2571782400 20 # 1 Jul 1981 +2603318400 21 # 1 Jul 1982 +2634854400 22 # 1 Jul 1983 +2698012800 23 # 1 Jul 1985 +2776982400 24 # 1 Jan 1988 +2840140800 25 # 1 Jan 1990 +2871676800 26 # 1 Jan 1991 +2918937600 27 # 1 Jul 1992 +2950473600 28 # 1 Jul 1993 +2982009600 29 # 1 Jul 1994 +3029443200 30 # 1 Jan 1996 +3076704000 31 # 1 Jul 1997 +3124137600 32 # 1 Jan 1999 +3345062400 33 # 1 Jan 2006 +3439756800 34 # 1 Jan 2009 +3550089600 35 # 1 Jul 2012 +3644697600 36 # 1 Jul 2015 +# +# 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 ~/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 +# expiration time of the file, but not the +# white space on those lines. +# the hash line is also ignored in the +# computation. +# +#h 44a44c49 35b22601 a9c7054c 8c56cf57 9b6f6ed5 # -#h 620ba8af 37900668 95ac09ba d77640f9 6fd75493 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
