eggert@cs.ucla.edu said:
but I worry that the format change will also mess up downstream programs too (notably NTP-related)
Worked OK for ntpsec. There is a checksum in the file, but it only covers the non-comment digits in the file. (so white space changes are OK) The payload lines must start on column 1 - no leading white space. -- These are my opinions. I hate spam.
Hal Murray wrote:
Worked OK for ntpsec.
There is a checksum in the file, but it only covers the non-comment digits in the file. (so white space changes are OK)
Good to know. So any problems should be limited to programs that try to parse the comments (such as the program in tzcode itself).
On 2019-01-19 15:54, Paul Eggert wrote:
Hal Murray wrote:
Worked OK for ntpsec.
There is a checksum in the file, but it only covers the non-comment digits in the file. (so white space changes are OK)
Good to know. So any problems should be limited to programs that try to parse the comments (such as the program in tzcode itself).
The NTP leap seconds file SHA1 check programs from IERS, Meinberg, or NIST hash all the digit characters not after a comment character, plus the update and expiry NTP times in the special comments lines, per the spec: "Although the program uses the standard algorithm specified in FIPS 180-1, the algorithm is applied only to a portion of the leap second file. Specifically: 1. comment lines, which start with # are not included when a comment signal is read, the comment begins at that point and continues to the end of the line 2. white space characters in non-comment lines are not included 3. the numerical values (but not the white space) in the two special lines #$ and #@ are included." and compares the result to the hex contents of the hash comment line. -- 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 -
Hal Murray -
Paul Eggert