Updated Public Domain leapseconds.list
# -=*( This file is in the public domain )*=- # This NTP leap-second file was created with data obtained from # the United States Naval Observatory (USNO) MAIA FTP server. # # Find it at: <ftp://maia.usno.navy.mil/ser7/leapsec.dat> # Updated using information from IERS Bulletin C 58 (4 Jul 2019) # Found at <ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat> # # Bulletin C 58 did not announce a new leap-second. # The last leap-second occurred on 1 Jan 2017 (3692217600). # # -=<*>=- # # This file is not produced by a national metrology laboratory. # It *is* created using data from one: # # United States Naval Observatory (USNO) # IERS Rapid Service/Prediction Center for Earth Orientation # 3450 Massachusetts Ave NW, Washington, DC 20392 # # It should be noted that anyone with proper information can # generate an NTP leap-seconds.list file. # # This file's generation was originally necessitated by a U.S. # government shutdown and the resulting lack of an NIST or USNO # generated file until late in January 2019. # # -=<*>=- # # The Network Time Protocol (NTP) keeps time in Coordinated # Universal Time (UTC). UTC is a time scale based upon # Standard International (SI) seconds and derived from Temps # Atomique International (TAI). UTC is the basis for legal # time since 1 Jan 1972 0h. # # [Le] Bureau International des Poids et Mesures (BIPM) tracks # TAI, UT1, TE and UTC uses a weighted ensemble of 420+ atomic # clocks at over 80+ national metrology laboratories worldwide # to track time and Very-Long-Baseline Interferometry (VLBI) # for precision millisecond pulsars timing and to track Earth's # orientation in space. The origin of TAI has been agreed # officially to coincide with UT1 on 1 January 1958 0h. # # For further information, read BIPM monograph "Time Scales" # found at: # # <https://www.bipm.org/... # utils/common/pdf/monographies-misc/Monographie1994-1.pdf> # # And "Coordinated Universal Time" at: # # <https://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-32_noteUTC.pdf> # # And, lastly: # # "Atomic Time Scales for Dynamical Astronomy" pp.51-56 # # "How Can Millisecond Pulsars Improve the Long-Term Stability # of Atomic Time Scales?", pp.57-60: # # Proceedings of the 6th European Frequency and Time Forum # (17-19 March 1992) # # <http://www.eftf.org/proceedings/proceedingsEFTF1992.pdf> # # -=<*>=- # # Leap seconds are an official correction to UTC to keep it # within 0.9 seconds of UT1; yet another time standard # based upon the orientation of the earth in space (and the # basis of legal time until 1972). IERS Bulletin A keeps # track of and predicts the value of UT1-UTC. # # See: http://maia.usno.navy.mil/ser7/ser7.txt # # The data kept in "leap-seconds.list" are used by the # Network Time Protocol daemon (NTPd) to determine when to # apply leap seconds to Coordinated Universal Time (UTC). # "leap-seconds.list" is a symbolic link to the actual # file name, leap-seconds.xxxxxxxxxx, where xxxxxxxxxx # is derived from the NTP update timestamp (below). # # Theoretically, a leap second may be positive or negative. # Realistically, negative leap seconds are unlikely to occur. # # All timestamps in this leap seconds file are encoded using the # NTP epoch. These timestamps represent the number of seconds # since 1 Jan 1900 0:00:00. This is Modified Julian Date (MJD) # 15020 and Julian Date 2415020.5. There will be an unsigned # 32-bit overflow to the second NTP era in 2036 (07 Feb 2036 # 06:28:16 UTC to be precise). # # A leap second datum consists of an NTP timestamp and the # number of seconds difference between TAI and UTC (e.g. # currently TAI-UTC is 37). UTC was established (at # midnight) on 1 Jan 1972 0h with TAI-UTC started at 10. # There was no mechanism prior to that time defining when # to apply leap seconds. # # Note: the first datum in the leap-seconds.list file is # *not* a leap-second; it denotes the definition of the # UTC timescale. # # Leap-seconds rules are establish in: # # International Telecommunications Union-Recommendation (ITU-R) # 460-6 (Standard-frequency and Time-Signal Emissions), # Annex 1 (Time scales), Section 2 (Leap-Seconds). # # Note: Version 460-6 of the Recommendation is incorporated # by reference in the [ITU] Radio Regulations. # # <http://www.itu.int/rec/R-REC-TF.460-6-200202-I/> # # Section 2.3: Delegates leap-second timing/dissemination to the # International Earth Rotation and Reference System Service (IERS), # (in its role as inheritor of Bureau International de l'Heure (BIH)). # # NTP Leap second files have an update time (#$). This is often # the UTC zero (0) hour time of the day when the leap second file # is built. [I am of the opinion] it should be updated whenever # a new IERS Bulletin C is issued. CCW] # #$ 3771187200 # # Leap second data have a lifetime. Traditionally, this ends on # the twenty-eighth (28) day of the month six months after the # period of time described in the latest IERS Bulletin C. This # is the expiry time (#@). # # File expires on: 28 Jun 2020 # #@ 3802291200 # # Leap second files have a hash, as define in NIST's FIPS 180 # Secure Hash Standard (SHS), current revision 4 (FIPS 180-4). # # FIPS Publications: <http://csrc.nist.gov/publications/fips/> # Direct Link: <http://dx.doi.org/10.6028/NIST.FIPS.180-4> # # It is based on an SHA[1] digest, created using the data # portions of the file including leap second data and the update # and expiry timestamps. All "white space" and comments are # ignored in the computation thereof. The 160-bit SHA[1] # digest polynomial are encoded in five hexadecimal grouping at # the end of the file (#h). The hash itself is NOT included in # the SHA[1]. It can also be calculated using GNU sha1sum which # generates the same 160-bit digest, given the same data, in # forty hexadecimal characters. # # Additionally, there may be an "#SHA256" digest record. If # present, it is a FIPS-180 SHA256 digest that includes the # same records as "#h" plus the comment Day, Month and Year # included in each NTP leap-second record (thus making it # possible to *verify* those comments as well as the file time- # stamps, and NTP leap-second data. # # NTP delta #timestamp T Date of Change # 2272060800 10 # 1 Jan 1972 (MJD 41317) 2287785600 11 # 1 Jul 1972 (MJD 41499) 2303683200 12 # 1 Jan 1973 (MJD 41683) 2335219200 13 # 1 Jan 1974 (MJD 42048) 2366755200 14 # 1 Jan 1975 (MJD 42413) 2398291200 15 # 1 Jan 1976 (MJD 42778) 2429913600 16 # 1 Jan 1977 (MJD 43144) 2461449600 17 # 1 Jan 1978 (MJD 43509) 2492985600 18 # 1 Jan 1979 (MJD 43874) 2524521600 19 # 1 Jan 1980 (MJD 44239) 2571782400 20 # 1 Jul 1981 (MJD 44786) 2603318400 21 # 1 Jul 1982 (MJD 45151) 2634854400 22 # 1 Jul 1983 (MJD 45516) 2698012800 23 # 1 Jul 1985 (MJD 46247) 2776982400 24 # 1 Jan 1988 (MJD 47161) 2840140800 25 # 1 Jan 1990 (MJD 47892) 2871676800 26 # 1 Jan 1991 (MJD 48257) 2918937600 27 # 1 Jul 1992 (MJD 48804) 2950473600 28 # 1 Jul 1993 (MJD 49169) 2982009600 29 # 1 Jul 1994 (MJD 49534) 3029443200 30 # 1 Jan 1996 (MJD 50083) 3076704000 31 # 1 Jul 1997 (MJD 50630) 3124137600 32 # 1 Jan 1999 (MJD 51179) 3345062400 33 # 1 Jan 2006 (MJD 53736) 3439756800 34 # 1 Jan 2009 (MJD 54832) 3550089600 35 # 1 Jul 2012 (MJD 56109) 3644697600 36 # 1 Jul 2015 (MJD 57204) 3692217600 37 # 1 Jan 2017 (MJD 57754) # #SHA256: 128f9463dc3828a1c7a611a4017bc311aabdfbe4c33fd8278a63bed7ef3ba0e2 #h bca6f457 5f358e20 a63e0aab a79ad3c3 c0a21083
On 2019-07-05 15:55, Chris Woodbury via tz wrote:
# This NTP leap-second file was created with data obtained from # the United States Naval Observatory (USNO) MAIA FTP server. # # Find it at: <ftp://maia.usno.navy.mil/ser7/leapsec.dat>
Seems to be some DNS resolver and network blocking, possibly only outside the US, to maia.usno.navy.mil and www.usno.navy.mil; interactive web browser access to tycho.usno.navy.mil and aa.usno.navy.mil mostly work, but web browser ftp access does not, and non web browser resolution and access do not, e.g. host or wget; however everything resolves and is accessible form the browser and command line from toshi.nofs.navy.mil. Some other previous reports back this up, but there were no followups to say whether issues were temporary and cleared up, or persisted and were permanent. It may be possible that lookups or accesses may be rate limited to deter intrusions, or entries may have expired because they may be offline for July 4 thru the weekend, or sites may be blocked due to lack of monitoring staff or funding for non-defense services. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
On Sat 2019-07-06T10:12:26-0600 Brian Inglis hath writ:
Seems to be some DNS resolver and network blocking, possibly only outside the US, to maia.usno.navy.mil and www.usno.navy.mil; interactive web browser access to tycho.usno.navy.mil and aa.usno.navy.mil mostly work
"mostly work" is consistent with our recent robotic telescope experience. We have a longstanding procedure to retrieve Bulletin A every week. In the past couple of months that has been failing, so we have modified the script to try more than once. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
On 2019-07-06 11:07, Steve Allen wrote:
On Sat 2019-07-06T10:12:26-0600 Brian Inglis hath writ:
Seems to be some DNS resolver and network blocking, possibly only outside the US, to maia.usno.navy.mil and www.usno.navy.mil; interactive web browser access to tycho.usno.navy.mil and aa.usno.navy.mil mostly work
"mostly work" is consistent with our recent robotic telescope experience. We have a longstanding procedure to retrieve Bulletin A every week. In the past couple of months that has been failing, so we have modified the script to try more than once.
Maybe we need not be too paranoid then about being alien data users. They give an example script and README: https://toshi.nofs.navy.mil/getusnoeop.README https://toshi.nofs.navy.mil/getusnoeop.ksh using maia.usno.navy.mil as primary and toshi.nofs.navy.mil as secondary. I would follow that example but switch primary and secondary, as toshi has been more accessible and reliable in recent months (so far, fingers crossed), reduce time spent trying each server, and try to get newer data from any usable servers. When there have been access and reliability problems in the past, as with NIST FTP and other mirror lists, it usually works better and faster to reduce wget -T timeout (900s) and -t tries (20) to low single digits, and cycle thru the mirrors list, with short sleeps between servers, and longer sleeps between cycles, dropping candidates with DNS or connection problems (as they are unlikely to clear up quickly). If the candidates list gets emptied, it gets reset from the mirrors list. The cycle continues until all required data files have been retrieved for checking or updating, or cycle count or time limits are reached. I tend to limit trying and failing, and let tomorrow's or next week's run deal with it. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
participants (3)
-
Brian Inglis -
Chris Woodbury -
Steve Allen