On Wednesday, January 26, 2005, at 08:21 AM, Todd Vierling wrote:

> On Wed, 26 Jan 2005, Matthias Buelow wrote:
>
>>> Just my thought: why signed 32 bit values? Unsigned should buy 
>>> something
>>> like
>>> 100 more years, and I don't think many programs use negative values 
>>> (but I
>>> might be very wrong)
>>
>> time(3) (and a number other functions that return time_t) returns -1 
>> as an
>> error condition.  And time(3) is a standard C function, so it can't 
>> just be
>> changed.
>
> Standards can and do change.  The Open Group Issue 6 spec, at least, 
> does
> not comment on the signedness of time_t except to say that error 
> values for
> things like time(3) are "(time_t)-1" -- indicating that unsigned 
> values are
> likely allowed by the spec thanks to the cast.
>
> That said, there's a lot of legacy code that does "... < 0" or "... == 
> -1"
> rather than the standard specified "... == (time_t)-1", which will 
> break if
> time_t is unsigned (but gcc will warn about this condition).
>

Consider, also,  time comparisons, unsigned would required the use of a 
larger type
to do compares.  time_t time1, time2 ;   time2 - time1 , if one can't 
guarantee
that time2 is larger (more recent ) than time1 , then unsigned would be 
problematic
, you'd underflow, and get a larger result.  Consider what would unix 
second  1 minus unix second 5  would be.  Do you want -4 seconds, which 
tells that time2 is smaller , older, and the difference is 4 or do you 
want 4 'til unix rollover?  That the results of operations
on time_t to still fit into time_t is desirable.