Paul Eggert wrote on 1998-10-05 21:02 UTC:
Date: Sun, 04 Oct 1998 11:43:30 +0100 From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>
"D. J. Bernstein" wrote on 1998-10-03 02:23 UTC:
In libtai, tai_now() and taia_now() always succeed.
I think this claim is a bit unrealistic.
But do you agree that Bernstein's library could be used to implement a version of xtime_get(...,TIME_TAI) that always succeeds, so long as it never sets the TIME_SYNC bit of the result? In other words, so long as xtime_get never _claims_ to be accurate within 1 s, it would conform to your spec.
I don't want to forbid this interpretation of the standard, so yes, I would say it could be used. (see below for why) For high quality implementations, I would prefer to see that implementations know what they do not know. For instance, I think a leap second table should have an expire date (at the moment this would be around 12 months), because the information necessary to update it (IERS Bulletin C) is distributed every six months, and if a leap second table has not been updated for more than 12 months than it is very likely that using it beyond the last known TAI-UTC offset will lead to wrong results. Note that implementations who are happy with such a best effort estimate of TAI can always use tz_jump to go back to the last known leap second and use xtime_conv() to read out the offset at that time. So even if the current TIME_TAI becomes unavailable due to an aging leap second table, with a bit more effort, applications can still get a more dangerous best effort estimate. TIME_SYNC in TIME_TAI and TIME_UTC has basically the same meaning (i.e., we have now a link to a reference clock), while the availability of TIME_TAI means that we have reason to believe that we know what the current UTC-TAI value is (or we otherwise have received TAI directly in cases where we don't know UTC at all). Do you think the specification should be formulated stricter here and if yes, what would be your preferred formulation? Please keep in mind that my goal was to write an easily understandable specification that allows but does not enforce high quality implementations. Therefore I intentionally left details open, like when exactly is TIME_TAI allowed to be available, because how to do this correctly depends a lot on to what resources the system has access. We can always add additional stricter requirements to the C API later in separate documents, for instance in further ISO standards about time protocols to be used in POSIX environments (with beautiful facilities for fully automated remote timezone and UTC-TAI table updates, etc.). Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>