[LEAPSECS] Lets get REAL about time.

[Poul-Henning Kamp]

In message <83DFD8CE-FA06-49A7-B9A8-A562F1EB145E at bsdimp.com>, Warner Losh write
s:


>> 1) You'll get pushback against floating-point, especially quad

>>FP.  Benchmarks and data challenges are a good way to make the case.

>>What is the cost to "get REAL" versus current libraries for different

>>classes of systems and applications?

>

>And how do kernels convert from integer to float?


If a kernel internally maintains time as 64.64 integer, turning this into
a binary128 floating point value is a matter of stuffing the 64.64 into
the mantissa field and normalizing the FP.

Notice that I have not specified that the actual syscall must use FP, the
conversion from 64.64 to FP could, and probably should, happen in libc.

The major trouble right now, is that the time-types in POSIX sucks.

If we want to improve it, we should make sure the improvement is
an improvement.  The choice of FP is to make time act like a sensible
variable in programs, which would be a big improvement over timeval
and similar crap:

	if (t1 - t0 > 0.25)
		do_that();

And FP is also indicated because binary128 is the only variable
type currently in existence big enough to hold timestamps with
sufficient resolution.


>> 2) There is nothing magic about the 1000 year horizon.  Certainly

>> science cases extend very much further into the past and future.


1000 years was chosen as a bare minimum to estimate miniumum number of
bits needed.

With binary128 we get 112 bits, which is enought to time individual
QED events in the Carboniferous Era.


>> 3) How does this interoperate with Julian date, another

>> floating-point format?  Note that Modified Julian Date (MJD) was

>> implemented precisely to avoid the extended precision needed to

>> simultaneously support high precision and wide date ranges.


There is no difference in the number of bits necessary, MJD is
just a scale and an offset away from my realtime_t type.

I think it is important that the unit of the representation is a
second rather than a day, simply because most of the stuff computers
do are in the second domain, not in the day domain.  (See code example
above)


>My question, though: if the offset is in TAI, and you have to

>support "UTC", how do you get your leap second tables to do the

>conversion?  


The reason for TAI is that way the kernel will not need the leapseconds
only userland will.

libc will need an updated table of leap-seconds to give you UTC,
and if you hand it a timestamp that is more than some set delta-T
from the last entry in the leapsecond table, it will return E2BIG
rather than give you a potentially wrong timestamp.

NTP can transfer the leap-second table these days, and all sorts
of software update mechanisms could as well.

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