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# Judah Levine 126# Time and Frequency Division 127# NIST 128# Boulder, Colorado 129# jlevine@boulder.nist.gov 130# 131# Last Update of leap second values: 11 January 2012 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#$ 3535228800 140# 141# The NTP timestamps are in units of seconds since the NTP epoch, 142# which is 1900.0. The Modified Julian Day number corresponding 143# to the NTP time stamp, X, can be computed as 144# 145# X/86400 + 15020 146# 147# where the first term converts seconds to days and the second 148# term adds the MJD corresponding to 1900.0. The integer portion 149# of the result is the integer MJD for that day, and any remainder 150# is the time of day, expressed as the fraction of the day since 0 151# hours UTC. The conversion from day fraction to seconds or to 152# hours, minutes, and seconds may involve rounding or truncation, 153# depending on the method used in the computation. 154# 155# The data in this file will be updated periodically as new leap 156# seconds are announced. In addition to being entered on the line 157# above, the update time (in NTP format) will be added to the basic 158# file name leap-seconds to form the name leap-seconds.<NTP TIME>. 159# In addition, the generic name leap-seconds.list will always point to 160# the most recent version of the file. 161# 162# This update procedure will be performed only when a new leap second 163# is announced. 164# 165# The following entry specifies the expiration date of the data 166# in this file in units of seconds since 1900.0. This expiration date 167# will be changed at least twice per year whether or not a new leap 168# second is announced. These semi-annual changes will be made no 169# later than 1 June and 1 December of each year to indicate what 170# action (if any) is to be taken on 30 June and 31 December, 171# respectively. (These are the customary effective dates for new 172# leap seconds.) This expiration date will be identified by a 173# unique pair of characters in columns 1 and 2 as shown below. 174# In the unlikely event that a leap second is announced with an 175# effective date other than 30 June or 31 December, then this 176# file will be edited to include that leap second as soon as it is 177# announced or at least one month before the effective date 178# (whichever is later). 179# If an announcement by the IERS specifies that no leap second is 180# scheduled, then only the expiration date of the file will 181# be advanced to show that the information in the file is still 182# current -- the update time stamp, the data and the name of the file 183# will not change. 184# 185# Updated through IERS Bulletin C46 186# File expires on: 28 June 2014 187# 188#@ 3612902400 189# 1902272060800 10 # 1 Jan 1972 1912287785600 11 # 1 Jul 1972 1922303683200 12 # 1 Jan 1973 1932335219200 13 # 1 Jan 1974 1942366755200 14 # 1 Jan 1975 1952398291200 15 # 1 Jan 1976 1962429913600 16 # 1 Jan 1977 1972461449600 17 # 1 Jan 1978 1982492985600 18 # 1 Jan 1979 1992524521600 19 # 1 Jan 1980 2002571782400 20 # 1 Jul 1981 2012603318400 21 # 1 Jul 1982 2022634854400 22 # 1 Jul 1983 2032698012800 23 # 1 Jul 1985 2042776982400 24 # 1 Jan 1988 2052840140800 25 # 1 Jan 1990 2062871676800 26 # 1 Jan 1991 2072918937600 27 # 1 Jul 1992 2082950473600 28 # 1 Jul 1993 2092982009600 29 # 1 Jul 1994 2103029443200 30 # 1 Jan 1996 2113076704000 31 # 1 Jul 1997 2123124137600 32 # 1 Jan 1999 2133345062400 33 # 1 Jan 2006 2143439756800 34 # 1 Jan 2009 2153550089600 35 # 1 Jul 2012 216# 217# the following special comment contains the 218# hash value of the data in this file computed 219# use the secure hash algorithm as specified 220# by FIPS 180-1. See the files in ~/pub/sha for 221# the details of how this hash value is 222# computed. Note that the hash computation 223# ignores comments and whitespace characters 224# in data lines. It includes the NTP values 225# of both the last modification time and the 226# expiration time of the file, but not the 227# white space on those lines. 228# the hash line is also ignored in the 229# computation. 230# 231#h 1151a8f e85a5069 9000fcdb 3d5e5365 1d505b37 232