Kurt Roeckx <Q@ping.be> writes:
> I had a discussion about time_t some weeks ago. There is nothing
> in the standard that says time_t must be a signed, all it says is
> that (time_t)(-1) represents an invalid value.
Don't get me started :-(
No sane person (certainly no one born before 1970) would think that
there is no need to represent pre-1970 dates. Also, anyone who harbors
ambitions of still being around 40 years from now will realize that the
current 32-bit range of time_t is inadequate. Fortunately, Moore's law
will save us. We can simply move to a 64-bit, signed representation of
time_t, maintaining the 1970 origin for compatibility's sake. That will
hold us till, if not the heat death of the universe, at least an epoch
where no one will blink an eye at 128-bit time_t. It will also provide
a standardized representation for pre-1901 times, something we lack now.
Given that that's surely where we'll be in a few years, I can see no
reason to abandon the past and pretend that time_t should be unsigned.
The special case for -1 is certainly a wart, but it's not a flaw in the
datatype definition, just a bug in the APIs of a few libc routines that
couldn't be bothered with providing a separate error return value.
These routines could be deprecated, the same way the ones with
non-reentrant APIs have been deprecated.
AFAIK all the old-line Unix implementations consider time_t signed.
I quote for example the HPUX man page for mktime():
If the calendar time cannot be represented, the
function returns the value (time_t)-1 and sets errno
to ERANGE. Note the value (time_t)-1 also
corresponds to the time 23:59:59 on Dec 31, 1969
(plus or minus time zone and Daylight Saving Time
adjustments). Thus it is necessary to check both
the return value and errno to reliably detect an
error condition.
In any case, making the type unsigned hardly makes the -1 special case
go away, it simply moves it out to 2100-something.
regards, tom lane
