[LEAPSECS] Lets get REAL about time.

Poul-Henning Kamp phk at phk.freebsd.dk
Sat Jan 21 07:31:49 EST 2012

In message <CACzrW9CcP982N_TBtY_ST3XBsD_+HAZw0+oftTrCWb_6MHb2FQ at mail.gmail.com>
, Stephen Colebourne writes:

>> >There is an IEEE spec for a large decimal number, which would be

>> >preferable. Or a 96/128 bit integer.


>> Only, it is not implemented anywhere, binary128 is.


>Fine, but I'm very unenthused about floating point numbers in general.

>I'm not sure you've made your case for not using a 128 bit integer,

>defined as (say) attoseconds.

First of all, I'm not particular wild about floating point numbers,
but the fact of the matter is that:

A: Time is measured in seconds, with a fractional part.
B: We want a datatype which supports normal sums and differences.

Both of which point to a floating point format, where operations
will naturally do what people expect from them.

Representing time in a integer count of a decimal fraction of
seconds is a really bad idea on a binary computer, that just leads
to bugs. It also means that numeric contants for common time
intervals like "1 second" become unweildy constants in the
program. See timeval/timespec use for plenty of such messes.

If you want a 128bit counter format, the units should be "1/2^N"
for some suitable N, most likely 64. This would be workable,
but still suffers from unweildy constants, in particular
for time intervals less than a second.

I've come to the conclusion that we have two choices: Either a
totally opaque time-type, which can only be operated on with
function calls that understand it, or we can lay it out in
a floating point type that intuitively does what people expect
with common algebraic operations.

The latter is clearly preferable, if the objective is to reduce
the number of mistakes programmers make.

>Exactly why I was asking about the purpose of this API. I'm not seeing

>it as a time API.

My intention was that this would be API that interfaces programs
to the operating systems (ie: kernels) timekeeping facility.

>My concern with what you have proposed is

>that the second part (the time-zone part) does imply a time API, but

>without sufficient control.

What controls are missing ?

>The JSR-310 spec effectively only requires a clock source from the OS.

And my API specifies the API to that clock source.

>Currently, my view is that the low-level API that you are defining

>should offer all three of the above, as they are the building blocks

>for everything else.


>Finally, I do think that if its called TAI, then it should use the TAI


No, to aid finding programmer bugs, it should use an epoch that will
generate large errors if^H^Hwhen programmers make mistakes.

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.

More information about the LEAPSECS mailing list