[LEAPSECS] Lets get REAL about time.
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