Newsgroups: comp.std.c Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: ANSI C date & time library functions. Message-ID: <1990Feb10.215957.25390@utzoo.uucp> Organization: U of Toronto Zoology References: <1990Feb9.183316.24925@utzoo.uucp> <15919@haddock.ima.isc.com> Date: Sat, 10 Feb 90 21:59:57 GMT In article <15919@haddock.ima.isc.com> karl@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@zoo.toronto.edu