Antoine Leca wrote on 1998-06-15 11:21 UTC:
The most compatible solution would be to use Markus Kuhn's CLOCK_UTC with nanosecond values up to 1999999999 during leap seconds (and if the system clock ticks TAI the library handles the conversion using a leap second table). This would however require new interfaces for time conversion that take times with nanoseconds.
This seems feasable; I have just a question: when there is a "step" leap second, i.e. when Terra is turning faster (clocks are going from 23:59:58 to 00:00:00), how is it supposed to be handled in this mechanism?
You just jump from (time_t) tv_sec to (time_t) tv_sec+1. Remember that (time_t) is just an encoding of a clock display and not necessarily a physical seconds counter. I have just written a Web page about my suggestions for POSIX clocks that handle leap seconds adequately: http://www.cl.cam.ac.uk/~mgk25/posix-clocks.html At the beginning of this text, you will find references to a number of documents that explain leap seconds and related concepts. For instance, have a look at ITU-R Recommendation TF.460-4, which is the definition of UTC and how its leap seconds work. TF.460-4 defines what a UTC clock displays during a positive and negative leap second, and we just encode this straight forward into struct time_spec. There just wasn't so far a way defined how to encode a seconds field containing the value 60, but adding 1_000_000_000 to the nanosecond field seems to be a practical way of extending the set of time displays that struct timespec can encode for the required inserted leap second. There is no need to encode a removed leap second, because you will not be able to produce a time stamp during a removed leap second. 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/>