[LEAPSECS] Lets get REAL about time.

[Poul-Henning Kamp]

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.


Exactly.


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

>epoch. 


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.