pike.git / lib / modules / Calendar.pmod / tzdata / leap-seconds.list

version» Context lines:

pike.git/lib/modules/Calendar.pmod/tzdata/leap-seconds.list:40:   #   # 2. The UTC time scale is realized by many national   # laboratories and timing centers. Each laboratory   # identifies its realization with its name: Thus   # UTC(NIST), UTC(USNO), etc. The differences among   # these different realizations are typically on the   # order of a few nanoseconds (i.e., 0.000 000 00x s)   # and can be ignored for many purposes. These differences   # are tabulated in Circular T, which is published monthly   # by the International Bureau of Weights and Measures - # (BIPM). See www.bipm.fr for more information. + # (BIPM). See www.bipm.org for more information.   #   # 3. The current definition of the relationship between UTC   # and TAI dates from 1 January 1972. A number of different   # time scales were in use before that epoch, and it can be   # quite difficult to compute precise timestamps and time   # intervals in those "prehistoric" days. For more information,   # consult:   #   # The Explanatory Supplement to the Astronomical   # Ephemeris.
pike.git/lib/modules/Calendar.pmod/tzdata/leap-seconds.list:120:   # methods, the second method is technically not correct because it adds   # the extra second to the wrong day.   #   # This complexity would not be needed for negative leap seconds (if they   # are ever used). The UTC time would skip 23:59:59 and advance from   # 23:59:58 to 00:00:00 in that case. The TAI offset would decrease by   # 1 second at the same instant. This is a much easier situation to deal   # with, since the difficulty of unambiguously representing the epoch   # during the leap second does not arise.   # + # Some systems implement leap seconds by amortizing the leap second + # over the last few minutes of the day. The frequency of the local + # clock is decreased (or increased) to realize the positive (or + # negative) leap second. This method removes the time step described + # above. Although the long-term behavior of the time scale is correct + # in this case, this method introduces an error during the adjustment + # period both in time and in frequency with respect to the official + # defintion of UTC. + #   # Questions or comments to:   # Judah Levine   # Time and Frequency Division   # NIST   # Boulder, Colorado   # Judah.Levine@nist.gov   # - # Last Update of leap second values: 11 January 2012 + # Last Update of leap second values: 5 January 2015   #   # The following line shows this last update date in NTP timestamp   # format. This is the date on which the most recent change to   # the leap second data was added to the file. This line can   # be identified by the unique pair of characters in the first two   # columns as shown below.   # - #$ 3535228800 + #$ 3629404800   #   # The NTP timestamps are in units of seconds since the NTP epoch,   # which is 1 January 1900, 00:00:00. The Modified Julian Day number   # corresponding to the NTP time stamp, X, can be computed as   #   # X/86400 + 15020   #   # where the first term converts seconds to days and the second   # term adds the MJD corresponding to the time origin defined above.   # The integer portion of the result is the integer MJD for that
pike.git/lib/modules/Calendar.pmod/tzdata/leap-seconds.list:183:   # effective date other than 30 June or 31 December, then this   # file will be edited to include that leap second as soon as it is   # announced or at least one month before the effective date   # (whichever is later).   # If an announcement by the IERS specifies that no leap second is   # scheduled, then only the expiration date of the file will   # be advanced to show that the information in the file is still   # current -- the update time stamp, the data and the name of the file   # will not change.   # - # Updated through IERS Bulletin C48 - # File expires on: 28 June 2015 + # Updated through IERS Bulletin C49 + # File expires on: 28 December 2015   # - #@ 3644438400 + #@ 3660249600   #   2272060800 10 # 1 Jan 1972   2287785600 11 # 1 Jul 1972   2303683200 12 # 1 Jan 1973   2335219200 13 # 1 Jan 1974   2366755200 14 # 1 Jan 1975   2398291200 15 # 1 Jan 1976   2429913600 16 # 1 Jan 1977   2461449600 17 # 1 Jan 1978   2492985600 18 # 1 Jan 1979
pike.git/lib/modules/Calendar.pmod/tzdata/leap-seconds.list:214:   2871676800 26 # 1 Jan 1991   2918937600 27 # 1 Jul 1992   2950473600 28 # 1 Jul 1993   2982009600 29 # 1 Jul 1994   3029443200 30 # 1 Jan 1996   3076704000 31 # 1 Jul 1997   3124137600 32 # 1 Jan 1999   3345062400 33 # 1 Jan 2006   3439756800 34 # 1 Jan 2009   3550089600 35 # 1 Jul 2012 + 3644697600 36 # 1 Jul 2015   #   # the following special comment contains the   # hash value of the data in this file computed   # use the secure hash algorithm as specified   # by FIPS 180-1. See the files in ~/pub/sha for   # the details of how this hash value is   # computed. Note that the hash computation   # ignores comments and whitespace characters   # in data lines. It includes the NTP values   # of both the last modification time and the   # expiration time of the file, but not the   # white space on those lines.   # the hash line is also ignored in the   # computation.   # - #h a4862ccd c6f43c6 964f3604 85944a26 b5cfad4e + #h 45e70fa7 a9df2033 f4a49ab0 ec648273 7b6c22c