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.