Re: [LEAPSECS] Internet-Draft on UTC-SLS

From: Poul-Henning Kamp <>
Date: Thu, 19 Jan 2006 12:59:42 +0100

In message <>, Markus Kuhn writes:
>Poul-Henning Kamp wrote on 2006-01-19 09:46 UTC:
>> >
>> The serious timekeeping people gave up on rubberseconds in 1972 and
>> I will object with all that I can muster against reinventing them
>> to paste over a problem that has a multitude of correct solutions.
>Just for the record, am I right in assuming that your point is already
>fully addressed in the UTC-SLS FAQ at

No it doesn't.

My objection is that you invent a new kind of seconds with new durations
instead of sticking with the SI second that we know and love.

Furthermore, you significantly loosen the precision specs set forth
in the NTP protocol.

And rather than have one focused moment where things can go wrong,
you have now streched that out over 1000 seconds.

1000 seconds is an incredible silly chosen number in an operational
context. At the very least make it 15, 30 or 60 minutes.

But mostly I object to it being a kludge rather than a solution.

By pasting over problems the way you propose, you are almost
guaranteed to prevent them from ever being resolved a right way.
(In this context either of fixing/extending POSIX or killing leap
seconds counts as "a right way" in my book.)

So rather than waste time and energy on something as badly thought
out as this, I would far rather we tried to define a time API for
POSIX to adopt that makes sense.

By make sense I mean:

        o conforms to relevant international standards
          ie: recognizes the defininition of leap seconds since
          for all purposes and intents we're probably stuck with
          the blasted things for another 20 years.

        o is workable from a computer architecture point of view
          no more pseudo-decimal timeval/timespec idiocy.

        o Caters to the needs of relevant user communities.

Here's a strawman:

        Use a 128 bit signed integer.

        Assign the top 120 bits as one integer field with
        resolution of 1/2^56 seconds.

        Assign the bottom 8 bits to an enum containing the
        timescale in question.

        Assign different timescales very different
        numeric epochs:
                TAI: 1972-01-01 00:00:00 UTC
                UTC: MJD's epoch.
                UT1: Flamsteads birthday ?
                NTP: defined in RFC1305

        Define functions to convert from one timescale
        to another and define ERANGE as a return value when
        outside the functions ability to do so (ie: future
        dates on UTC).

        Define a compact ascii (no i18n!) representation for machine
        readable use. (Ie: XML, protocols etc).

        Very clearly spell out that any timezone adjustments
        must be carried out-of-band to this field.

        Assign the UTC timescale a identifier of zero.


        Sufficient resolution to represent any likely physical
        measurement or realizable frequency for the forseeable
        future (13.8e-18 seconds resolution).

        Extracting the whole second part can be done by accessing
        only the top 64 bits (which are enough to contain all
        of history and then some).

        Conversion to/from NTP timestamps is trivial.

        Conversion to time_t is a matter of addition and extraction
        of the relevant 32 bits.

        The binary format makes for fast and efficient arithmetic.

        By assigning the UTC timescale an identifier of zero,
        the majority of implementations can disrecard the
        multiple timescale aspect in total.

        Small platform implementations can use a smaller width,
        for instance 64 bits split 48/16 and easily transform
        to standard format by zero extension.

        High quality implementations will check the bottom 8 bits
        for identity and fail operations that mix but don't match

        Different epochs will make it painfully obvious when people
        mix but don't match timescales in low quality implementations.

Now, please show some backbone and help solve the problem rather
than add to the general kludgyness of computers.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Thu Jan 19 2006 - 04:10:06 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT