leap-seconds.list revision 309568
11558Srgrimes# 21558Srgrimes# In the following text, the symbol '#' introduces 31558Srgrimes# a comment, which continues from that symbol until 41558Srgrimes# the end of the line. A plain comment line has a 51558Srgrimes# whitespace character following the comment indicator. 61558Srgrimes# There are also special comment lines defined below. 71558Srgrimes# A special comment will always have a non-whitespace 81558Srgrimes# character in column 2. 91558Srgrimes# 101558Srgrimes# A blank line should be ignored. 111558Srgrimes# 121558Srgrimes# The following table shows the corrections that must 131558Srgrimes# be applied to compute International Atomic Time (TAI) 141558Srgrimes# from the Coordinated Universal Time (UTC) values that 151558Srgrimes# are transmitted by almost all time services. 161558Srgrimes# 171558Srgrimes# The first column shows an epoch as a number of seconds 181558Srgrimes# since 1 January 1900, 00:00:00 (1900.0 is also used to 191558Srgrimes# indicate the same epoch.) Both of these time stamp formats 201558Srgrimes# ignore the complexities of the time scales that were 211558Srgrimes# used before the current definition of UTC at the start 221558Srgrimes# of 1972. (See note 3 below.) 231558Srgrimes# The second column shows the number of seconds that 241558Srgrimes# must be added to UTC to compute TAI for any timestamp 251558Srgrimes# at or after that epoch. The value on each line is 261558Srgrimes# valid from the indicated initial instant until the 271558Srgrimes# epoch given on the next one or indefinitely into the 281558Srgrimes# future if there is no next line. 291558Srgrimes# (The comment on each line shows the representation of 301558Srgrimes# the corresponding initial epoch in the usual 311558Srgrimes# day-month-year format. The epoch always begins at 321558Srgrimes# 00:00:00 UTC on the indicated day. See Note 5 below.) 331558Srgrimes# 341558Srgrimes# Important notes: 3523675Speter# 361558Srgrimes# 1. Coordinated Universal Time (UTC) is often referred to 371558Srgrimes# as Greenwich Mean Time (GMT). The GMT time scale is no 381558Srgrimes# longer used, and the use of GMT to designate UTC is 391558Srgrimes# discouraged. 4023675Speter# 411558Srgrimes# 2. The UTC time scale is realized by many national 421558Srgrimes# laboratories and timing centers. Each laboratory 431558Srgrimes# identifies its realization with its name: Thus 4423799Sbde# UTC(NIST), UTC(USNO), etc. The differences among 4523675Speter# these different realizations are typically on the 4623675Speter# order of a few nanoseconds (i.e., 0.000 000 00x s) 4723799Sbde# and can be ignored for many purposes. These differences 4823675Speter# are tabulated in Circular T, which is published monthly 491558Srgrimes# by the International Bureau of Weights and Measures 501558Srgrimes# (BIPM). See www.bipm.org for more information. 511558Srgrimes# 521558Srgrimes# 3. The current definition of the relationship between UTC 5323675Speter# and TAI dates from 1 January 1972. A number of different 547585Sbde# time scales were in use before that epoch, and it can be 557585Sbde# quite difficult to compute precise timestamps and time 561558Srgrimes# intervals in those "prehistoric" days. For more information, 571558Srgrimes# consult: 581558Srgrimes# 591558Srgrimes# The Explanatory Supplement to the Astronomical 601558Srgrimes# Ephemeris. 611558Srgrimes# or 621558Srgrimes# Terry Quinn, "The BIPM and the Accurate Measurement 631558Srgrimes# of Time," Proc. of the IEEE, Vol. 79, pp. 894-905, 641558Srgrimes# July, 1991. 651558Srgrimes# 661558Srgrimes# 4. The decision to insert a leap second into UTC is currently 671558Srgrimes# the responsibility of the International Earth Rotation and 681558Srgrimes# Reference Systems Service. (The name was changed from the 691558Srgrimes# International Earth Rotation Service, but the acronym IERS 701558Srgrimes# is still used.) 711558Srgrimes# 721558Srgrimes# Leap seconds are announced by the IERS in its Bulletin C. 731558Srgrimes# 741558Srgrimes# See www.iers.org for more details. 751558Srgrimes# 761558Srgrimes# Every national laboratory and timing center uses the 777585Sbde# data from the BIPM and the IERS to construct UTC(lab), 781558Srgrimes# their local realization of UTC. 791558Srgrimes# 801558Srgrimes# Although the definition also includes the possibility 811558Srgrimes# of dropping seconds ("negative" leap seconds), this has 821558Srgrimes# never been done and is unlikely to be necessary in the 831558Srgrimes# foreseeable future. 841558Srgrimes# 851558Srgrimes# 5. If your system keeps time as the number of seconds since 861558Srgrimes# some epoch (e.g., NTP timestamps), then the algorithm for 871558Srgrimes# assigning a UTC time stamp to an event that happens during a positive 881558Srgrimes# leap second is not well defined. The official name of that leap 891558Srgrimes# second is 23:59:60, but there is no way of representing that time 901558Srgrimes# in these systems. 911558Srgrimes# Many systems of this type effectively stop the system clock for 921558Srgrimes# one second during the leap second and use a time that is equivalent 931558Srgrimes# to 23:59:59 UTC twice. For these systems, the corresponding TAI 941558Srgrimes# timestamp would be obtained by advancing to the next entry in the 951558Srgrimes# following table when the time equivalent to 23:59:59 UTC 961558Srgrimes# is used for the second time. Thus the leap second which 971558Srgrimes# occurred on 30 June 1972 at 23:59:59 UTC would have TAI 981558Srgrimes# timestamps computed as follows: 991558Srgrimes# 1001558Srgrimes# ... 1011558Srgrimes# 30 June 1972 23:59:59 (2287785599, first time): TAI= UTC + 10 seconds 1021558Srgrimes# 30 June 1972 23:59:60 (2287785599,second time): TAI= UTC + 11 seconds 1031558Srgrimes# 1 July 1972 00:00:00 (2287785600) TAI= UTC + 11 seconds 1041558Srgrimes# ... 1051558Srgrimes# 1061558Srgrimes# If your system realizes the leap second by repeating 00:00:00 UTC twice 1071558Srgrimes# (this is possible but not usual), then the advance to the next entry 1081558Srgrimes# in the table must occur the second time that a time equivalent to 1091558Srgrimes# 00:00:00 UTC is used. Thus, using the same example as above: 1101558Srgrimes# 1111558Srgrimes# ... 1121558Srgrimes# 30 June 1972 23:59:59 (2287785599): TAI= UTC + 10 seconds 1137585Sbde# 30 June 1972 23:59:60 (2287785600, first time): TAI= UTC + 10 seconds 1141558Srgrimes# 1 July 1972 00:00:00 (2287785600,second time): TAI= UTC + 11 seconds 1151558Srgrimes# ... 1161558Srgrimes# 1171558Srgrimes# in both cases the use of timestamps based on TAI produces a smooth 1181558Srgrimes# time scale with no discontinuity in the time interval. However, 1191558Srgrimes# although the long-term behavior of the time scale is correct in both 1201558Srgrimes# methods, the second method is technically not correct because it adds 1211558Srgrimes# the extra second to the wrong day. 1221558Srgrimes# 12323675Speter# This complexity would not be needed for negative leap seconds (if they 1241558Srgrimes# are ever used). The UTC time would skip 23:59:59 and advance from 1251558Srgrimes# 23:59:58 to 00:00:00 in that case. The TAI offset would decrease by 1261558Srgrimes# 1 second at the same instant. This is a much easier situation to deal 1271558Srgrimes# with, since the difficulty of unambiguously representing the epoch 1281558Srgrimes# during the leap second does not arise. 1291558Srgrimes# 1301558Srgrimes# Some systems implement leap seconds by amortizing the leap second 1311558Srgrimes# over the last few minutes of the day. The frequency of the local 1321558Srgrimes# clock is decreased (or increased) to realize the positive (or 1331558Srgrimes# negative) leap second. This method removes the time step described 1341558Srgrimes# above. Although the long-term behavior of the time scale is correct 1351558Srgrimes# in this case, this method introduces an error during the adjustment 13623675Speter# period both in time and in frequency with respect to the official 1371558Srgrimes# definition of UTC. 1381558Srgrimes# 1391558Srgrimes# Questions or comments to: 1401558Srgrimes# Judah Levine 1411558Srgrimes# Time and Frequency Division 1421558Srgrimes# NIST 1431558Srgrimes# Boulder, Colorado 1441558Srgrimes# Judah.Levine@nist.gov 1451558Srgrimes# 1461558Srgrimes# Last Update of leap second values: 8 July 2016 1471558Srgrimes# 1481558Srgrimes# The following line shows this last update date in NTP timestamp 1491558Srgrimes# format. This is the date on which the most recent change to 1501558Srgrimes# the leap second data was added to the file. This line can 1511558Srgrimes# be identified by the unique pair of characters in the first two 1521558Srgrimes# columns as shown below. 15323675Speter# 1541558Srgrimes#$ 3676924800 1551558Srgrimes# 1561558Srgrimes# The NTP timestamps are in units of seconds since the NTP epoch, 1571558Srgrimes# which is 1 January 1900, 00:00:00. The Modified Julian Day number 1581558Srgrimes# corresponding to the NTP time stamp, X, can be computed as 1591558Srgrimes# 1601558Srgrimes# X/86400 + 15020 1611558Srgrimes# 1621558Srgrimes# where the first term converts seconds to days and the second 1631558Srgrimes# term adds the MJD corresponding to the time origin defined above. 1641558Srgrimes# The integer portion of the result is the integer MJD for that 16523675Speter# day, and any remainder is the time of day, expressed as the 1661558Srgrimes# fraction of the day since 0 hours UTC. The conversion from day 1671558Srgrimes# fraction to seconds or to hours, minutes, and seconds may involve 1681558Srgrimes# rounding or truncation, depending on the method used in the 1691558Srgrimes# computation. 1701558Srgrimes# 1711558Srgrimes# The data in this file will be updated periodically as new leap 1721558Srgrimes# seconds are announced. In addition to being entered on the line 1731558Srgrimes# above, the update time (in NTP format) will be added to the basic 1741558Srgrimes# file name leap-seconds to form the name leap-seconds.<NTP TIME>. 1751558Srgrimes# In addition, the generic name leap-seconds.list will always point to 1761558Srgrimes# the most recent version of the file. 1771558Srgrimes# 1781558Srgrimes# This update procedure will be performed only when a new leap second 1791558Srgrimes# is announced. 1801558Srgrimes# 1811558Srgrimes# The following entry specifies the expiration date of the data 1821558Srgrimes# in this file in units of seconds since the origin at the instant 18323675Speter# 1 January 1900, 00:00:00. This expiration date will be changed 1841558Srgrimes# at least twice per year whether or not a new leap second is 1851558Srgrimes# announced. These semi-annual changes will be made no later 18623675Speter# than 1 June and 1 December of each year to indicate what 1871558Srgrimes# action (if any) is to be taken on 30 June and 31 December, 1881558Srgrimes# respectively. (These are the customary effective dates for new 1891558Srgrimes# leap seconds.) This expiration date will be identified by a 1901558Srgrimes# unique pair of characters in columns 1 and 2 as shown below. 1911558Srgrimes# In the unlikely event that a leap second is announced with an 1921558Srgrimes# effective date other than 30 June or 31 December, then this 1931558Srgrimes# file will be edited to include that leap second as soon as it is 1941558Srgrimes# announced or at least one month before the effective date 1951558Srgrimes# (whichever is later). 1961558Srgrimes# If an announcement by the IERS specifies that no leap second is 1971558Srgrimes# scheduled, then only the expiration date of the file will 1987585Sbde# be advanced to show that the information in the file is still 1991558Srgrimes# current -- the update time stamp, the data and the name of the file 2001558Srgrimes# will not change. 2011558Srgrimes# 2021558Srgrimes# Updated through IERS Bulletin C52 2031558Srgrimes# File expires on: 28 June 2017 2041558Srgrimes# 2051558Srgrimes#@ 3707596800 2061558Srgrimes# 2071558Srgrimes2272060800 10 # 1 Jan 1972 2081558Srgrimes2287785600 11 # 1 Jul 1972 2091558Srgrimes2303683200 12 # 1 Jan 1973 2101558Srgrimes2335219200 13 # 1 Jan 1974 2111558Srgrimes2366755200 14 # 1 Jan 1975 2121558Srgrimes2398291200 15 # 1 Jan 1976 2131558Srgrimes2429913600 16 # 1 Jan 1977 2141558Srgrimes2461449600 17 # 1 Jan 1978 2151558Srgrimes2492985600 18 # 1 Jan 1979 2161558Srgrimes2524521600 19 # 1 Jan 1980 2171558Srgrimes2571782400 20 # 1 Jul 1981 2181558Srgrimes2603318400 21 # 1 Jul 1982 2191558Srgrimes2634854400 22 # 1 Jul 1983 2201558Srgrimes2698012800 23 # 1 Jul 1985 2211558Srgrimes2776982400 24 # 1 Jan 1988 2221558Srgrimes2840140800 25 # 1 Jan 1990 2231558Srgrimes2871676800 26 # 1 Jan 1991 22423675Speter2918937600 27 # 1 Jul 1992 2251558Srgrimes2950473600 28 # 1 Jul 1993 2261558Srgrimes2982009600 29 # 1 Jul 1994 22723675Speter3029443200 30 # 1 Jan 1996 2281558Srgrimes3076704000 31 # 1 Jul 1997 2291558Srgrimes3124137600 32 # 1 Jan 1999 2301558Srgrimes3345062400 33 # 1 Jan 2006 2311558Srgrimes3439756800 34 # 1 Jan 2009 2321558Srgrimes3550089600 35 # 1 Jul 2012 2331558Srgrimes3644697600 36 # 1 Jul 2015 23423675Speter3692217600 37 # 1 Jan 2017 2351558Srgrimes# 2361558Srgrimes# the following special comment contains the 2377585Sbde# hash value of the data in this file computed 23823675Speter# use the secure hash algorithm as specified 23923675Speter# by FIPS 180-1. See the files in ~/pub/sha for 2401558Srgrimes# the details of how this hash value is 2411558Srgrimes# computed. Note that the hash computation 24223675Speter# ignores comments and whitespace characters 2431558Srgrimes# in data lines. It includes the NTP values 2441558Srgrimes# of both the last modification time and the 2451558Srgrimes# expiration time of the file, but not the 2461558Srgrimes# white space on those lines. 2471558Srgrimes# the hash line is also ignored in the 2481558Srgrimes# computation. 2491558Srgrimes# 2501558Srgrimes#h dacf2c42 2c4765d6 3c797af8 2cf630eb 699c8c67 2511558Srgrimes