In message <199809182051.NAA01889@shell7.ba.best.com>, Nathan Myers <ncm@best.com> writes:
Can we discuss the rest of the proposal? The URL was: http://www.cl.cam.ac.uk/~mgk25/c-time/
Well, part of the reason for my focusing on the trivial issue of what to name the basic data type is that I'm pretty happy with the real substance. 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. ? --Ken Pizzini