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