|
| 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 1 January 1900, 00:00:00 (1900.0 is also used to |
| 19 | +# indicate the same epoch.) Both of these time stamp formats |
| 20 | +# ignore the complexities of the time scales that were |
| 21 | +# used before the current definition of UTC at the start |
| 22 | +# of 1972. (See note 3 below.) |
| 23 | +# The second column shows the number of seconds that |
| 24 | +# must be added to UTC to compute TAI for any timestamp |
| 25 | +# at or after that epoch. The value on each line is |
| 26 | +# valid from the indicated initial instant until the |
| 27 | +# epoch given on the next one or indefinitely into the |
| 28 | +# future if there is no next line. |
| 29 | +# (The comment on each line shows the representation of |
| 30 | +# the corresponding initial epoch in the usual |
| 31 | +# day-month-year format. The epoch always begins at |
| 32 | +# 00:00:00 UTC on the indicated day. See Note 5 below.) |
| 33 | +# |
| 34 | +# Important notes: |
| 35 | +# |
| 36 | +# 1. Coordinated Universal Time (UTC) is often referred to |
| 37 | +# as Greenwich Mean Time (GMT). The GMT time scale is no |
| 38 | +# longer used, and the use of GMT to designate UTC is |
| 39 | +# discouraged. |
| 40 | +# |
| 41 | +# 2. The UTC time scale is realized by many national |
| 42 | +# laboratories and timing centers. Each laboratory |
| 43 | +# identifies its realization with its name: Thus |
| 44 | +# UTC(NIST), UTC(USNO), etc. The differences among |
| 45 | +# these different realizations are typically on the |
| 46 | +# order of a few nanoseconds (i.e., 0.000 000 00x s) |
| 47 | +# and can be ignored for many purposes. These differences |
| 48 | +# are tabulated in Circular T, which is published monthly |
| 49 | +# by the International Bureau of Weights and Measures |
| 50 | +# (BIPM). See www.bipm.org for more information. |
| 51 | +# |
| 52 | +# 3. The current definition of the relationship between UTC |
| 53 | +# and TAI dates from 1 January 1972. A number of different |
| 54 | +# time scales were in use before that epoch, and it can be |
| 55 | +# quite difficult to compute precise timestamps and time |
| 56 | +# intervals in those "prehistoric" days. For more information, |
| 57 | +# consult: |
| 58 | +# |
| 59 | +# The Explanatory Supplement to the Astronomical |
| 60 | +# Ephemeris. |
| 61 | +# or |
| 62 | +# Terry Quinn, "The BIPM and the Accurate Measurement |
| 63 | +# of Time," Proc. of the IEEE, Vol. 79, pp. 894-905, |
| 64 | +# July, 1991. <http://dx.doi.org/10.1109/5.84965> |
| 65 | +# reprinted in: |
| 66 | +# Christine Hackman and Donald B Sullivan (eds.) |
| 67 | +# Time and Frequency Measurement |
| 68 | +# American Association of Physics Teachers (1996) |
| 69 | +# <http://tf.nist.gov/general/pdf/1168.pdf>, pp. 75-86 |
| 70 | +# |
| 71 | +# 4. The decision to insert a leap second into UTC is currently |
| 72 | +# the responsibility of the International Earth Rotation and |
| 73 | +# Reference Systems Service. (The name was changed from the |
| 74 | +# International Earth Rotation Service, but the acronym IERS |
| 75 | +# is still used.) |
| 76 | +# |
| 77 | +# Leap seconds are announced by the IERS in its Bulletin C. |
| 78 | +# |
| 79 | +# See www.iers.org for more details. |
| 80 | +# |
| 81 | +# Every national laboratory and timing center uses the |
| 82 | +# data from the BIPM and the IERS to construct UTC(lab), |
| 83 | +# their local realization of UTC. |
| 84 | +# |
| 85 | +# Although the definition also includes the possibility |
| 86 | +# of dropping seconds ("negative" leap seconds), this has |
| 87 | +# never been done and is unlikely to be necessary in the |
| 88 | +# foreseeable future. |
| 89 | +# |
| 90 | +# 5. If your system keeps time as the number of seconds since |
| 91 | +# some epoch (e.g., NTP timestamps), then the algorithm for |
| 92 | +# assigning a UTC time stamp to an event that happens during a positive |
| 93 | +# leap second is not well defined. The official name of that leap |
| 94 | +# second is 23:59:60, but there is no way of representing that time |
| 95 | +# in these systems. |
| 96 | +# Many systems of this type effectively stop the system clock for |
| 97 | +# one second during the leap second and use a time that is equivalent |
| 98 | +# to 23:59:59 UTC twice. For these systems, the corresponding TAI |
| 99 | +# timestamp would be obtained by advancing to the next entry in the |
| 100 | +# following table when the time equivalent to 23:59:59 UTC |
| 101 | +# is used for the second time. Thus the leap second which |
| 102 | +# occurred on 30 June 1972 at 23:59:59 UTC would have TAI |
| 103 | +# timestamps computed as follows: |
| 104 | +# |
| 105 | +# ... |
| 106 | +# 30 June 1972 23:59:59 (2287785599, first time): TAI= UTC + 10 seconds |
| 107 | +# 30 June 1972 23:59:60 (2287785599,second time): TAI= UTC + 11 seconds |
| 108 | +# 1 July 1972 00:00:00 (2287785600) TAI= UTC + 11 seconds |
| 109 | +# ... |
| 110 | +# |
| 111 | +# If your system realizes the leap second by repeating 00:00:00 UTC twice |
| 112 | +# (this is possible but not usual), then the advance to the next entry |
| 113 | +# in the table must occur the second time that a time equivalent to |
| 114 | +# 00:00:00 UTC is used. Thus, using the same example as above: |
| 115 | +# |
| 116 | +# ... |
| 117 | +# 30 June 1972 23:59:59 (2287785599): TAI= UTC + 10 seconds |
| 118 | +# 30 June 1972 23:59:60 (2287785600, first time): TAI= UTC + 10 seconds |
| 119 | +# 1 July 1972 00:00:00 (2287785600,second time): TAI= UTC + 11 seconds |
| 120 | +# ... |
| 121 | +# |
| 122 | +# in both cases the use of timestamps based on TAI produces a smooth |
| 123 | +# time scale with no discontinuity in the time interval. However, |
| 124 | +# although the long-term behavior of the time scale is correct in both |
| 125 | +# methods, the second method is technically not correct because it adds |
| 126 | +# the extra second to the wrong day. |
| 127 | +# |
| 128 | +# This complexity would not be needed for negative leap seconds (if they |
| 129 | +# are ever used). The UTC time would skip 23:59:59 and advance from |
| 130 | +# 23:59:58 to 00:00:00 in that case. The TAI offset would decrease by |
| 131 | +# 1 second at the same instant. This is a much easier situation to deal |
| 132 | +# with, since the difficulty of unambiguously representing the epoch |
| 133 | +# during the leap second does not arise. |
| 134 | +# |
| 135 | +# Some systems implement leap seconds by amortizing the leap second |
| 136 | +# over the last few minutes of the day. The frequency of the local |
| 137 | +# clock is decreased (or increased) to realize the positive (or |
| 138 | +# negative) leap second. This method removes the time step described |
| 139 | +# above. Although the long-term behavior of the time scale is correct |
| 140 | +# in this case, this method introduces an error during the adjustment |
| 141 | +# period both in time and in frequency with respect to the official |
| 142 | +# definition of UTC. |
| 143 | +# |
| 144 | +# Questions or comments to: |
| 145 | +# Judah Levine |
| 146 | +# Time and Frequency Division |
| 147 | +# NIST |
| 148 | +# Boulder, Colorado |
| 149 | +# Judah.Levine@nist.gov |
| 150 | +# |
| 151 | +# Last Update of leap second values: 8 July 2016 |
| 152 | +# |
| 153 | +# The following line shows this last update date in NTP timestamp |
| 154 | +# format. This is the date on which the most recent change to |
| 155 | +# the leap second data was added to the file. This line can |
| 156 | +# be identified by the unique pair of characters in the first two |
| 157 | +# columns as shown below. |
| 158 | +# |
| 159 | +#$ 3676924800 |
| 160 | +# |
| 161 | +# The NTP timestamps are in units of seconds since the NTP epoch, |
| 162 | +# which is 1 January 1900, 00:00:00. The Modified Julian Day number |
| 163 | +# corresponding to the NTP time stamp, X, can be computed as |
| 164 | +# |
| 165 | +# X/86400 + 15020 |
| 166 | +# |
| 167 | +# where the first term converts seconds to days and the second |
| 168 | +# term adds the MJD corresponding to the time origin defined above. |
| 169 | +# The integer portion of the result is the integer MJD for that |
| 170 | +# day, and any remainder is the time of day, expressed as the |
| 171 | +# fraction of the day since 0 hours UTC. The conversion from day |
| 172 | +# fraction to seconds or to hours, minutes, and seconds may involve |
| 173 | +# rounding or truncation, depending on the method used in the |
| 174 | +# computation. |
| 175 | +# |
| 176 | +# The data in this file will be updated periodically as new leap |
| 177 | +# seconds are announced. In addition to being entered on the line |
| 178 | +# above, the update time (in NTP format) will be added to the basic |
| 179 | +# file name leap-seconds to form the name leap-seconds.<NTP TIME>. |
| 180 | +# In addition, the generic name leap-seconds.list will always point to |
| 181 | +# the most recent version of the file. |
| 182 | +# |
| 183 | +# This update procedure will be performed only when a new leap second |
| 184 | +# is announced. |
| 185 | +# |
| 186 | +# The following entry specifies the expiration date of the data |
| 187 | +# in this file in units of seconds since the origin at the instant |
| 188 | +# 1 January 1900, 00:00:00. This expiration date will be changed |
| 189 | +# at least twice per year whether or not a new leap second is |
| 190 | +# announced. These semi-annual changes will be made no later |
| 191 | +# than 1 June and 1 December of each year to indicate what |
| 192 | +# action (if any) is to be taken on 30 June and 31 December, |
| 193 | +# respectively. (These are the customary effective dates for new |
| 194 | +# leap seconds.) This expiration date will be identified by a |
| 195 | +# unique pair of characters in columns 1 and 2 as shown below. |
| 196 | +# In the unlikely event that a leap second is announced with an |
| 197 | +# effective date other than 30 June or 31 December, then this |
| 198 | +# file will be edited to include that leap second as soon as it is |
| 199 | +# announced or at least one month before the effective date |
| 200 | +# (whichever is later). |
| 201 | +# If an announcement by the IERS specifies that no leap second is |
| 202 | +# scheduled, then only the expiration date of the file will |
| 203 | +# be advanced to show that the information in the file is still |
| 204 | +# current -- the update time stamp, the data and the name of the file |
| 205 | +# will not change. |
| 206 | +# |
| 207 | +# Updated through IERS Bulletin C55 |
| 208 | +# File expires on: 28 December 2018 |
| 209 | +# |
| 210 | +#@ 3754944000 |
| 211 | +# |
| 212 | +2272060800 10 # 1 Jan 1972 |
| 213 | +2287785600 11 # 1 Jul 1972 |
| 214 | +2303683200 12 # 1 Jan 1973 |
| 215 | +2335219200 13 # 1 Jan 1974 |
| 216 | +2366755200 14 # 1 Jan 1975 |
| 217 | +2398291200 15 # 1 Jan 1976 |
| 218 | +2429913600 16 # 1 Jan 1977 |
| 219 | +2461449600 17 # 1 Jan 1978 |
| 220 | +2492985600 18 # 1 Jan 1979 |
| 221 | +2524521600 19 # 1 Jan 1980 |
| 222 | +2571782400 20 # 1 Jul 1981 |
| 223 | +2603318400 21 # 1 Jul 1982 |
| 224 | +2634854400 22 # 1 Jul 1983 |
| 225 | +2698012800 23 # 1 Jul 1985 |
| 226 | +2776982400 24 # 1 Jan 1988 |
| 227 | +2840140800 25 # 1 Jan 1990 |
| 228 | +2871676800 26 # 1 Jan 1991 |
| 229 | +2918937600 27 # 1 Jul 1992 |
| 230 | +2950473600 28 # 1 Jul 1993 |
| 231 | +2982009600 29 # 1 Jul 1994 |
| 232 | +3029443200 30 # 1 Jan 1996 |
| 233 | +3076704000 31 # 1 Jul 1997 |
| 234 | +3124137600 32 # 1 Jan 1999 |
| 235 | +3345062400 33 # 1 Jan 2006 |
| 236 | +3439756800 34 # 1 Jan 2009 |
| 237 | +3550089600 35 # 1 Jul 2012 |
| 238 | +3644697600 36 # 1 Jul 2015 |
| 239 | +3692217600 37 # 1 Jan 2017 |
| 240 | +# |
| 241 | +# the following special comment contains the |
| 242 | +# hash value of the data in this file computed |
| 243 | +# use the secure hash algorithm as specified |
| 244 | +# by FIPS 180-1. See the files in ~/pub/sha for |
| 245 | +# the details of how this hash value is |
| 246 | +# computed. Note that the hash computation |
| 247 | +# ignores comments and whitespace characters |
| 248 | +# in data lines. It includes the NTP values |
| 249 | +# of both the last modification time and the |
| 250 | +# expiration time of the file, but not the |
| 251 | +# white space on those lines. |
| 252 | +# the hash line is also ignored in the |
| 253 | +# computation. |
| 254 | +# |
| 255 | +#h 44dcf58c e28d25aa b36612c8 f3d3e8b5 a8fdf478 |
0 commit comments