C9x <time.h> and clock precision
eggert at twinsun.com
Mon Oct 5 20:44:34 UTC 1998
Date: Sun, 04 Oct 1998 12:03:49 +0100
From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>
You certainly do not measure the position of your radio telescope
with 3 cm precision (0.1 ns) by performing time request calls to
your C API! You would use external picosecond hardware phase
comparators clocked by caesium time normals, which send you the
data as ASCII floating point numbers for further processing in your
It sounds like you're saying that C should not support high-resolution
timestamps, and that people who need such things should use Fortran instead.
Perhaps I'm paraphrasing you incorrectly; still, I am extremely
uncomfortable with the idea that the C standard should impose an upper
limit on the quality of the clock.
It's reasonable for the C Standard to impose a _lower_ limit on clock
quality, just as it imposes a lower limit on the size of `int'. But
it's not reasonable for the standard to impose an upper limit, unless
there is a compelling justification, which is absent here. The
standard places no upper bound on the size of `int', and this is for a
good reason: we don't want to forbid higher-quality implementations.
I can't offhand recall any place in the existing standard that imposes
an upper bound on quality; I don't think <time.h> should either.
More information about the tz