Proposal for new ISO C 9x time API

[Markus Kuhn]

Ken Pizzini wrote on 1998-09-19 07:54 UTC:
> One other fragment that mildly bothers me is in the Implementation
> Advice to {xtime,chron{,os}}_conv(), where Markus has:
> :    Implementations can also offer the application to
> :   convert TIME_MONOTONIC values into TIME_TAI or TIME_UTC values as soon
> :   as these clocks have been adjusted using an external reference. This
> :   way, TIME_MONOTONIC values that were measured at a time when the   
> :   implementation had not yet been able to determine UTC or TAI can later
> :   be converted as soon as contact with the reference clock is
> :   established.
> 
> I feel that it would be helpful to further advise implementors on
> what they might do (or at least that it is an issue that they ought
> to consider) if, after synchronization with TIME_UTC or TIME_TAI
> becomes established, it is discovered that the TIME_MONOTONIC clock has
> been running with its "second" of a substantially different duration
> than a TAI second?  (Say, 0.1 TAI second/pre-sync monotone second,
> or 10 TAI seconds/pre-sync monotone second, perhaps due to a change
> in underlying hardware that the software is running on, and without a
> suitable pre-syncronization time base to calibrate to.  Even a (perhaps
> more realistic) 1.01 TAI second/monotone second could be considered
> "substantial" by some.)
> 
> Perhaps add a sentence along the lines of:
>    When making such a conversion, a high-quality implementation
>    would take into account any difference in clock-rates that may
>    have been discovered.

Significantly differing clock rates (larger than 1000 ppm) would clearly
be a hardware malfunction, and I don't think the C standard is the place
to address these. Typical cheap PC crystals have a frequency error of
usually much better than 300 ppm (mine here wandered in the last hour
between -15 and -22 ppm, says the ntpq command). The constant
manufacturing error and the time-dependent fluctuations (due to
temperature and voltage fluctuations) are roughly in the same order of
magnitude for office equipment. If you measure the frequency error as
soon as you got access to an external clock, this does not necessarily
significantly allow you to estimate the frequency error history of your
oscillator. Unless you have rather bad hardware with a quite severe
manufacturing error (in which case for instance NTP's control algorithms
would overflow and fail anyway), it is not very practical to offer an a
posteriori correction of the frequency error.

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