Newsgroups: comp.std.c Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: ANSI C date & time library functions. Message-ID: <1990Feb9.183316.24925@utzoo.uucp> Organization: U of Toronto Zoology References: Date: Fri, 9 Feb 90 18:33:16 GMT In article 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