On 2018-10-06 18:12, Paul Eggert wrote:
Arthur David Olson wrote:
Perhaps accept leap seconds at the ends of months other than June or December, but issue a warning? (And similarly for negative leap seconds?)
Although we could, there's lots of other stuff the script could check for, such as dates like "6 Oct 2018" (or "1 Winterfilth, SR 1453"...). Having the script properly validate its input (much less warn about implausible input) would significantly complicate it. If someone were to write such a validation I suppose we would accept it, but given the script's intended use I would give the project low priority.
A better line of attack (if someone wants to volunteer) would be for the script to parse the input data instead of scraping dates from comments in the input. Parsing the comments, as we do now, is surely asking for trouble. For example, in this input line:
3692217600 37 # 1 Jan 2017
the script currently ignores the 3692217600 which is the actual data, and parses the "1 Jan 2017". Eeeuuw.
Chris Woodbury recently sent me a patch to parse the data, but unfortunately his patch relied heavily on nonportable GNU extensions and I'd rather stick with plain POSIX tools. Chris also suggested that we stop using the NIST file entirely and switch to the USNO format; however that would rattle many of our downstream users, and it would possibly make the stick-with-POSIX approach even harder.
NTP times can be easily parsed, converted, and formatted using the NTP epoch with date -d "1900-01-01 00:00:00+000 + $NTPtime seconds": the attached script checks the SHA1, converts, and reports the dates: bashisms allow easy param pattern content cleanup, but could be replaced. The script is adhoc, but adequate with wrappers run weekdays for the first couple of weeks every six months, to get, check, and update /etc/leap-seconds.list from sources, and run processes. USNO also provides leap-seconds files in NTP format from: ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.* where leap-seconds.list is a symlink to leap-seconds.# and # is the update NTP time e.g. 3739787886. -- 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.