Phil W Lee wrote:
Martin Burnicki <martin.burni...@meinberg.de> considered Tue, 16 Dec
2014 14:23:15 +0100 the perfect time to write:
Harlan Stenn wrote:
An alternative is that we get enough support to advance NTF's General
Timestamp API, and then we can run systems on either TAI or UTC and
these conversions will happen automatically.
Since timescale files in the GTSAPI are "versioned", one could still use
an obsolete leapsecond file, and while those UTC timestamps would be
"wrong" if a new leapsecond was added, these timestamps would be
correctable when a new version of the UTC timescale file was available.
Hm, that may not really help if the API returns a wrong UTC time stamp
which is then used to set the system time wrong.
The tzdist protocol could also be helpful here to provide the
information required to do the conversion correctly. An expiration date
could be used for versioning.
Martin
You don't need an expiry date if you have a version number and/or an
authoritative source for any new version that may be available - you
just compare the two, and use the newest available.
Yes you do. With only a version number "consumers" like ntpd would not
be able to know if the information is outdated, or not.
Of course, if leap seconds should be abolished it would be useful to
support a pseudo expiration date meaning "until further notice".
As long as the IERS stays at the same URL, you could just use their
file at http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second.dat
(although it would be useful if that file was more complete, with a
version number and checksum).
This is once more a different file format than the format used by
tzdata, or NIST/NTP. :-(
A service like a tzdist client, or a simple script which might look for
and download updated files, could report an error if the URL is not
reachable, and thus it can't even *check* if a new "version" of the file
is available.
However, similarly as not every tiny NTP client node should query the
time directly from NIST and similar servers but should use pool servers
instead, not every tiny embedded system should try to download a leap
second file directly from the primary server.
If they use secondary servers an older version of the file may me
available, but outdated. No way to check this without an expiration date.
There are companies with a whole (sub-)network without access to the
internet, so it may be required to update DST rules and leap second
information manually. An easy way to do this could be to set up a tzdist
or FTP (or whatever) server which can provide the internal clients with
the update.
If no one cares about those updates then applications like ntpd can
output a warning if the expiration date has been passed. With only a
version information this isn't possible.
It would also be useful if they used SSL, and changed the url to
https://etc.
Agreed.
Martin
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
