🚀 go-pugleaf

In article <1990Feb9.183316.24925@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <DAVE.90Feb6112502@marvin.moncam.co.uk> dave@moncam.co.uk (Speaker-To-Animals) writes:
>>Are times more precise than 1 second only possible in implementations
>>with greater than 32 bit integers?
>
>... [time_t] could be floating-point.

>You are correct that a 32-bit integer isn't practical for time resolutions
>less than one second; indeed, it's increasingly marginal even at that
>resolution, since the times "go negative" less than fifty years from now.
>I'd say time_t is going to have to go to 64 bits (or perhaps to floating
>point) fairly soon.

Not necessarily.  An unsigned long would give us 32 bits (worst case) instead
of the current 31; this would push the "overflow date" into the 22nd century.
The need for sub-second resolution is the dominant requirement here.

As far as I can see, the only reason that it has to be arithmetic at all is so
that time() can return (time_t)-1 to flag an error.  This is rather bizarre,
since existing Unix implementations never return an error from time();
unfortunately, because existing code uses "t = time((time_t *)0);" in addition
to the equivalent "(void)time(&t);" to read the time, it appears that there
wasn't much choice.  I wonder if maybe "time()" should have been deprecated in
favor of a "gettime()" function that would only return 0 (filling in its
argument like time() does) or -1.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint