leap-seconds revision 295461
1# 2# $FreeBSD: stable/10/etc/ntp/leap-seconds 295461 2016-02-10 07:16:17Z cy $ 3# 4# In the following text, the symbol '#' introduces 5# a comment, which continues from that symbol until 6# the end of the line. A plain comment line has a 7# whitespace character following the comment indicator. 8# There are also special comment lines defined below. 9# A special comment will always have a non-whitespace 10# character in column 2. 11# 12# A blank line should be ignored. 13# 14# The following table shows the corrections that must 15# be applied to compute International Atomic Time (TAI) 16# from the Coordinated Universal Time (UTC) values that 17# are transmitted by almost all time services. 18# 19# The first column shows an epoch as a number of seconds 20# since 1900.0 and the second column shows the number of 21# seconds that must be added to UTC to compute TAI for 22# any timestamp at or after that epoch. The value on 23# each line is valid from the indicated initial instant 24# until the epoch given on the next one or indefinitely 25# into the future if there is no next line. 26# (The comment on each line shows the representation of 27# the corresponding initial epoch in the usual 28# day-month-year format. The epoch always begins at 29# 00:00:00 UTC on the indicated day. See Note 5 below.) 30# 31# Important notes: 32# 33# 1. Coordinated Universal Time (UTC) is often referred to 34# as Greenwich Mean Time (GMT). The GMT time scale is no 35# longer used, and the use of GMT to designate UTC is 36# discouraged. 37# 38# 2. The UTC time scale is realized by many national 39# laboratories and timing centers. Each laboratory 40# identifies its realization with its name: Thus 41# UTC(NIST), UTC(USNO), etc. The differences among 42# these different realizations are typically on the 43# order of a few nanoseconds (i.e., 0.000 000 00x s) 44# and can be ignored for many purposes. These differences 45# are tabulated in Circular T, which is published monthly 46# by the International Bureau of Weights and Measures 47# (BIPM). See www.bipm.fr for more information. 48# 49# 3. The current defintion of the relationship between UTC 50# and TAI dates from 1 January 1972. A number of different 51# time scales were in use before than epoch, and it can be 52# quite difficult to compute precise timestamps and time 53# intervals in those "prehistoric" days. For more information, 54# consult: 55# 56# The Explanatory Supplement to the Astronomical 57# Ephemeris. 58# or 59# Terry Quinn, "The BIPM and the Accurate Measurement 60# of Time," Proc. of the IEEE, Vol. 79, pp. 894-905, 61# July, 1991. 62# 63# 4. The insertion of leap seconds into UTC is currently the 64# responsibility of the International Earth Rotation Service, 65# which is located at the Paris Observatory: 66# 67# Central Bureau of IERS 68# 61, Avenue de l'Observatoire 69# 75014 Paris, France. 70# 71# Leap seconds are announced by the IERS in its Bulletin C 72# 73# See hpiers.obspm.fr or www.iers.org for more details. 74# 75# All national laboratories and timing centers use the 76# data from the BIPM and the IERS to construct their 77# local realizations of UTC. 78# 79# Although the definition also includes the possibility 80# of dropping seconds ("negative" leap seconds), this has 81# never been done and is unlikely to be necessary in the 82# foreseeable future. 83# 84# 5. If your system keeps time as the number of seconds since 85# some epoch (e.g., NTP timestamps), then the algorithm for 86# assigning a UTC time stamp to an event that happens during a positive 87# leap second is not well defined. The official name of that leap 88# second is 23:59:60, but there is no way of representing that time 89# in these systems. 90# Many systems of this type effectively stop the system clock for 91# one second during the leap second and use a time that is equivalent 92# to 23:59:59 UTC twice. For these systems, the corresponding TAI 93# timestamp would be obtained by advancing to the next entry in the 94# following table when the time equivalent to 23:59:59 UTC 95# is used for the second time. Thus the leap second which 96# occurred on 30 June 1972 at 23:59:59 UTC would have TAI 97# timestamps computed as follows: 98# 99# ... 100# 30 June 1972 23:59:59 (2287785599, first time): TAI= UTC + 10 seconds 101# 30 June 1972 23:59:60 (2287785599,second time): TAI= UTC + 11 seconds 102# 1 July 1972 00:00:00 (2287785600) TAI= UTC + 11 seconds 103# ... 104# 105# If your system realizes the leap second by repeating 00:00:00 UTC twice 106# (this is possible but not usual), then the advance to the next entry 107# in the table must occur the second time that a time equivlent to 108# 00:00:00 UTC is used. Thus, using the same example as above: 109# 110# ... 111# 30 June 1972 23:59:59 (2287785599): TAI= UTC + 10 seconds 112# 30 June 1972 23:59:60 (2287785600, first time): TAI= UTC + 10 seconds 113# 1 July 1972 00:00:00 (2287785600,second time): TAI= UTC + 11 seconds 114# ... 115# 116# in both cases the use of timestamps based on TAI produces a smooth 117# time scale with no discontinuity in the time interval. 118# 119# This complexity would not be needed for negative leap seconds (if they 120# are ever used). The UTC time would skip 23:59:59 and advance from 121# 23:59:58 to 00:00:00 in that case. The TAI offset would decrease by 122# 1 second at the same instant. This is a much easier situation to deal 123# with, since the difficulty of unambiguously representing the epoch 124# during the leap second does not arise. 125# 126# Questions or comments to: 127# Jeff Prillaman 128# Time Service Department 129# US Naval Observatory 130# Washington, DC 131# jeffrey.prillaman@usno.navy.mil 132# 133# Last Update of leap second values: 31 Dec 2015 134# 135# The following line shows this last update date in NTP timestamp 136# format. This is the date on which the most recent change to 137# the leap second data was added to the file. This line can 138# be identified by the unique pair of characters in the first two 139# columns as shown below. 140# 141#$ 3660508800 142# 143# The data in this file will be updated periodically as new leap 144# seconds are announced. In addition to being entered on the line 145# above, the update time (in NTP format) will be added to the basic 146# file name leap-seconds to form the name leap-seconds.<NTP TIME>. 147# In addition, the generic name leap-seconds.list will always point to 148# the most recent version of the file. 149# 150# This update procedure will be performed only when a new leap second 151# is announced. 152# 153# The following entry specifies the expiration date of the data 154# in this file in units of seconds since 1900.0. This expiration date 155# will be changed at least twice per year whether or not a new leap 156# second is announced. These semi-annual changes will be made no 157# later than 1 June and 1 December of each year to indicate what 158# action (if any) is to be taken on 30 June and 31 December, 159# respectively. (These are the customary effective dates for new 160# leap seconds.) This expiration date will be identified by a 161# unique pair of characters in columns 1 and 2 as shown below. 162# In the unlikely event that a leap second is announced with an 163# effective date other than 30 June or 31 December, then this 164# file will be edited to include that leap second as soon as it is 165# announced or at least one month before the effective date 166# (whichever is later). 167# If an announcement by the IERS specifies that no leap second is 168# scheduled, then only the expiration date of the file will 169# be advanced to show that the information in the file is still 170# current -- the update time stamp, the data and the name of the file 171# will not change. 172# 173# Updated through IERS Bulletin C 50 174# File expires on: 1 Jun 2016 175# 176#@ 3673728000 177# 1782272060800 10 # 1 Jan 1972 1792287785600 11 # 1 Jul 1972 1802303683200 12 # 1 Jan 1973 1812335219200 13 # 1 Jan 1974 1822366755200 14 # 1 Jan 1975 1832398291200 15 # 1 Jan 1976 1842429913600 16 # 1 Jan 1977 1852461449600 17 # 1 Jan 1978 1862492985600 18 # 1 Jan 1979 1872524521600 19 # 1 Jan 1980 1882571782400 20 # 1 Jul 1981 1892603318400 21 # 1 Jul 1982 1902634854400 22 # 1 Jul 1983 1912698012800 23 # 1 Jul 1985 1922776982400 24 # 1 Jan 1988 1932840140800 25 # 1 Jan 1990 1942871676800 26 # 1 Jan 1991 1952918937600 27 # 1 Jul 1992 1962950473600 28 # 1 Jul 1993 1972982009600 29 # 1 Jul 1994 1983029443200 30 # 1 Jan 1996 1993076704000 31 # 1 Jul 1997 2003124137600 32 # 1 Jan 1999 2013345062400 33 # 1 Jan 2006 2023439756800 34 # 1 Jan 2009 2033550089600 35 # 1 Jul 2012 2043644697600 36 # 1 Jul 2015 205# 206# the following special comment contains the 207# hash value of the data in this file computed 208# use the secure hash algorithm as specified 209# by FIPS 180-1. See the files in ~/sha for 210# the details of how this hash value is 211# computed. Note that the hash computation 212# ignores comments and whitespace characters 213# in data lines. It includes the NTP values 214# of both the last modification time and the 215# expiration time of the file, but not the 216# white space on those lines. 217# the hash line is also ignored in the 218# computation. 219# 220#h 44a44c49 35b22601 a9c7054c 8c56cf57 9b6f6ed5 221# 222