<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" class="gmail_attr">On Fri, 1 Feb 2019 at 07:44, Tony Finch <<a href="mailto:dot@dotat.at">dot@dotat.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Paul Eggert <<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>> wrote:<br>><br>> One cannot simply translate the IERS file to the NIST file, as the NIST file<br>> has information that the IERS file lacks, namely, the last time that the data<br>> were changed.<br><br>Isn't that always 5ish months before the last leap second? :-)</blockquote></div><div dir="ltr"><br></div><div dir="ltr">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).</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--<br>Tim Parenti</div></div></div></div>