C9x <time.h> and clock precision

Paul Eggert 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
   Fortran tools

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 mailing list