In message <4f19885c.3090...@sfr.fr>, mike cook writes: >> 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.
No, time_t is entirely in front of the binary point: It counts seconds. We need something which will also do the fractions of seconds and without braindamage of the "struct timeval" type. >> 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. PTP already uses TAI TAI can be derived from UTC, GPS and other broadcast timescales, so availability is fine. -- 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
