comments on draft ISO C9x changes to <time.h>

[Markus Kuhn]

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