🚀 go-pugleaf

In article <DAVE.90Feb6112502@marvin.moncam.co.uk> dave@moncam.co.uk (Speaker-To-Animals) writes:
>... time_t is described as a scalar type.  difftime() returns
>the difference between two times as a double.  If time_t represents a time
>in centiseconds (say), a 32-bit unsigned value will cover a period of a year
>or so.  Are times more precise than 1 second only possible in implementations 
>with greater than 32 bit integers?  Since time() returns -1 if the time is
>not available, it doesn't seem possible to define time_t as an array of
>integers.

Unless this changed since the Oct 88 draft, time_t is not constrained to
be a scalar type, only to be an arithmetic type.  That is, it could be
floating-point.  It also might be some implementation-specific type like
"long long int".  Furthermore, there is no guarantee that you can do
useful arithmetic on time_t values; the encoding of the time in a time_t
is explicitly unspecified, the only constraint being that `(time_t) -1'
must not be a valid time.  The inability to do arithmetic is the reason
why difftime() exists.

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.
-- 
SVR4:  every feature you ever |     Henry Spencer at U of Toronto Zoology
wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu