[LEAPSECS] Lets get REAL about time.

[Warner Losh]

On Jan 20, 2012, at 10:54 PM, Rob Seaman wrote:


> Poul-Henning Kamp wrote:

> 

>> To avoid thread-divergence, I have collected some responses here:

> 

> Am happy to see such an effort and agree generally with previous comments, expecially Mark's and Steve's.  Will keep my editorial comments to a minimum (here) to squelch divergence, but I will point out that this of course doesn't address all civil timekeeping issues that have been discussed.

> 

> Regarding editorial comments, would suggest these be excised from the document but that points of software engineering be described in more detail than usual; the stakeholders and potential readers won't all be programmers.  For instance, examples of bad current usage should explain why they are bad.


I was thinking they should be split into an appendix...


>> Also, I disagree with choosing an epoch in the past to reduce exponent changes:  We should optimize to get maximum number of exponent changes initially, to make sure code handling that gets debugged.  We should probably even put the epoch into the future,

>> to also get handling of signs tested.  Lets make it 2026-01-20 instead.

> 

> An interesting strategy.  Some comments:

> 

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


> 2) There is nothing magic about the 1000 year horizon.  Certainly science cases extend very much further into the past and future.


If you have a design goal of 1000 years, then that's forever in CS terms.  It lets you show that the problem will be effectively solved with several bits to spare.  Those several bits might be used to leverage longer time horizons.  We have astronomical data from only the past 500 years to a high precision, and less precise back another 5000 years (is that right?)  But since my son loves dinosuars, I know they were 200M years ago, and the age of the earth is like 5B years and the age of the universe is 20B years.  That's about 1e18 seconds (if I did the math right) which is about 56 bits of SI seconds, which leaves 56 bits for the fraction (assuming it is float), which should be adequate for all users.  Unless I'm doing something wrong with the math somewhere...


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


MJD/JD are just transforms...  With 112 bits of precision, the reasons for MJD vs JD disappear.  They were made for when you had far fewer bits of precision...

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?  And do you use UTC'72 projected back into the past from 1972?  Or do you use the 10 rubber leap seconds to take us back to 1958?  and prior to that what do you use?

Warner