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 p...@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. _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs