[LEAPSECS] Lets get REAL about time.

Poul-Henning Kamp phk at phk.freebsd.dk
Sat Jan 21 09:50:57 EST 2012


In message <7ABCFE74-4BCC-40BF-8421-B0868A6C3A5D at noao.edu>, Rob Seaman writes:

>Poul-Henning Kamp wrote:

>

>> First of all, I'm not particular wild about floating point numbers,

>

>Then others will feel the same way and will always immediately

>cast the returned values into integers, either rounding to seconds,

>scaling to milli- or microseconds, or splitting into two ints holding

>the seconds and the fractional part.


As they well should, and well should be able to.

That's sort of the point really: Making sure programs do what
programmers expect them to do, without having to write an entire
book about how to find the time of day.

Representing time as a real number that acts the way real numbers
do, is the least confusing representation of time, as you yourself
pointed about in re: MJD.


>I'm not arguing against your position (perhaps for it), but the

>API should be designed to gracefully handle awkward usage. In

>particular, should truncating into 32-bit signed ints leave you in

>a "reasonable" range of dates?


32 bits of int counted in seconds only holds 136 years of time, so
you cannot ask that question without also asking "when" it should
be "a reasonable range of dates".

Having asked the question correctly, the answer is obvious: If
the programmer think that is a safe restriction on his program.


>> With binary128 we get 112 bits, which is enought to time individual

>> QED events in the Carboniferous Era.

>

>This was the point about the Planck time. The universe is big and

>time is long. No single API can address all use cases.


Using binary128 gets pretty damn close:

log10(2^112 / age of universe) = 16
log10(2^112 / 1000 years) = 23

(Technically speaking it should be 2^113, because we also have the sign).

I'm pretty sure the major criticism will be that the range (and thus
size) is far bigger than necessary.

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