libtai versus xtime

[Markus Kuhn]

"D. J. Bernstein" wrote on 1998-10-03 02:23 UTC:
> Markus Kuhn writes:
> > Before any arithmetic, you first
> > check whether there is a leap second in one of the arguments and abort
> > if there is (because arithmetic is ill-defined in this case).
> 
> Of course, libtai doesn't have that problem.
> 
> libtai provides support routines for addition, subtraction, comparison,
> halving, conversions to and from the external TAI64NA format, and
> floating-point approximations. Applications don't need to worry about
> the internal details.
> 
> > xtime_get can fail
> 
> In libtai, tai_now() and taia_now() always succeed.

I think this claim is a bit unrealistic. The only common hardware
platform where a correct and robust implementation of your libtai is
possible would be a GPS receiver that has been running for at least 12
minutes with an antenna outside a building. I am not sure, what the
scope of your API is, but that sounds somewhat restricted to me. I use
systems every day that might not know about TAI.

You might have defined yourself some sort of synthetic pseudo-TAI that
you send through various correction filters and adjust to the real TAI
whenever you have correct leap-second tables and an external UTC
reference available, but that in the end is not guaranteed to have a
reliable relation to the real TAI as published by BIPM/IERS. If it is
not TAI, then please do not call it TAI, or be accused of sloppy
terminology. If you use some not clearly defined pseudo-TAI, then in the
end what you provide is probably just one of the possible implementation
forms of xtime's TIME_MONOTONIC, which is also guaranteed to always
succeed, but which does not claim to have a relationship with TAI and
which can therefore even be implemented on embedded systems with no
non-volatile memory whatsoever and with no UTC or TAI reference. The
xtime API was designed for a much broader scope and I think is much
better suited as a template for an ISO standard.

I have looked at your libtai, and the claim that it doesn't have any
problems that the xtime API does have certainly does not hold up under
even superficial examination. The clock model in your API seems to be a
simplistic subset, and regarding the guarantees you make about the
availability of TAI it probably either uses misleading terminology or is
just not implementable in a robust and reliable way on many platforms.

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/>