Tim Parenti wrote:
On Fri, 1 Feb 2019 at 07:44, Tony Finch <dot@dotat.at <mailto:dot@dotat.at>> wrote:
Paul Eggert <eggert@cs.ucla.edu <mailto:eggert@cs.ucla.edu>> wrote: > > One cannot simply translate the IERS file to the NIST file, as the NIST file > has information that the IERS file lacks, namely, the last time that the data > were changed.
Isn't that always 5ish months before the last leap second? :-)
Well, both have a #$ line, but the purpose is slightly different. For NIST, the value is the last time that only the data were changed (currently 2016-07-08T00:00:00Z), but for IERS it's the last time the file as a whole was updated, including the metadata (currently 2019-01-07T14:19:26Z).
Basically the difference shouldn't matter much as long as the data in the file is correct, and the file has not expired. If the "last update" time changes whenever *any* of the information in the file has been updated you can always figure out which is the latest version of the file, even if an updated file becomes available for some reason in the middle of the interval between 2 bulletin Cs. So I'd even say the IERS way to do it makes more sense.
I would imagine, yes, IERS wouldn't be keen on adopting NIST's practices for this line, but I don't necessarily see the reverse change being particularly disruptive, if we were to take IERS' file as-is. In the worst case, anyone relying on the less-often-updated NIST version of the line would just end up pulling the same, unchanged data once every six months.
Jep. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy