ANSI C date & time library functions.

[Henry Spencer]

In article <15919 at haddock.ima.isc.com> karl at haddock.ima.isc.com (Karl Heuer) writes:
>>[32-bit time_t] times "go negative" less than fifty years from now...
>
>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.

Unfortunately, there's a major backward-compatibility issue here:  all the
Unix code which assumes that the difference of two time_t values is signed.
Yes, that code "really ought to" use difftime() to avoid this, and not doing
so limits its portability... but declaring it unportable is one thing, and
breaking it even in its native environment is another.  I don't think it's
worth the trouble for one bit.  We need a longer-term solution which also
(as Karl points out) addresses the issue of better resolution.

>...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()...

However, non-Unix implementations may have to, if they can't supply a time.
-- 
SVR4:  every feature you ever |     Henry Spencer at U of Toronto Zoology
wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry at zoo.toronto.edu