libtai versus xtime

[Markus Kuhn]

Paul Eggert wrote on 1998-10-05 21:02 UTC:
>    Date: Sun, 04 Oct 1998 11:43:30 +0100
>    From: Markus Kuhn <Markus.Kuhn at 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/>