[LEAPSECS] Lets get REAL about time.

[Poul-Henning Kamp]

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

Zefram writes:


> I think he was suggesting that you use the 1958-01-01 epoch that NASA (and

> I, in my desktop clock program) already use.


I disagree, as a matter of software quality assurance, it is important
to choose an epoch *nobody* else uses, so that conversions are forced
to be explicit, rather than assumed automatic.

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.

Steve Allen writes:


>Nothing can tick TAI seconds, for TAI is not known until next month,

>so at the nanosecond level that assumption must be false.


A lot of things can tick TAI seconds at he level of precision required
for most applications, and since the uncertainty is explicitly reported
in my API, any remaining applications will have the data needed to cope
or crash.


>>[deriving TAI from UTC etc]

>Indications have been that BIPM will disagree violently with that

>statement.


Only if you forget to specify the uncertainty.  If you remember to
specify the uncertainty, they're usually quite pleased.

Michael Deckers writes:


>   To set the scale, the finest resolution possible with

>   the time of day register in IBM zArchitecture machines

>   is 2^-52 =B5s =3D~ 0.2 zs, which is 3 orders of magnitude

>   below your proposal.


112 bits still leave us good room.

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