[LEAPSECS] Lets get REAL about time.

[mike cook]

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.


>