Le 20/01/2012 12:29, Poul-Henning Kamp a écrit :
Poul-Henning,
You obviously didn't scratch this out on the back of a matchbox and
as a contented daily consumer of your code I take it that you have
thought hard about it.
I would like to ask a couple of questions and comment.
With the leap-seconds still unresolved, it is time that we get real about
time in the computer business.
Our history is littered with failed representations of time.
Counting milliseconds since boot in a 32bit integer means your
operating system runs out of steam after 49 days.
Counting seconds since 1970 in 32 bit will be fun in 2038.
So lets get real, and fix this once and for all.
How many bits of resolution do we need ?
We want at least 1000 years range of our new type.
There are approximately 32 billion seconds in 1000 years, so we need
at least 35 bits in front of the binary point.
We also want resolution that can measure all relevant physical and
in particular all relevante computing timeintervals with an error less
than 0.1%.
Modern CPUs clock around 4GHz, multiplying by 1000 for resulution we
find that we need 42 bits after the binary point.
Solaris already has 64 bit quantities for time operations. From their doc:
"time_t, and its derivative types struct timeval and timespec_t now
contain 64-bit quantities"
Aren't you reinventing the wheel? Its open source, so just borrow it.
Our new timecale should run on the TAI timescale which does not
have leap-seconds or any other artifacts, and library functions can
convert that to UTC time, civil time etc, using a leap-second table
which can be updated as and when leap-seconds gets announced.
Fine, but if TAI is going to be adopted anytime as the standard of time
dissemination, nobody is going to be announcing leap seconds, UNLESS,
parallel time scales spring up.
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
