Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!tully.Berkeley.EDU!mcgrath
From: mcgrath@tully.Berkeley.EDU.berkeley.edu (Roland McGrath)
Newsgroups: comp.std.c
Subject: Re: The type of time_t (was: struct tm -> time_t converter wanted)
Message-ID: <26582@ucbvax.BERKELEY.EDU>
Date: 26 Oct 88 23:36:16 GMT
References: <442@grand.UUCP> <8700@smoke.BRL.MIL> <6964@cdis-1.uucp> <9816@haddock.ima.isc.com> <1988Oct22.230215.19411@utzoo.uucp>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: roland@wheaties.ai.mit.edu (Roland McGrath)
Organization: Hackers Anonymous International, Ltd., Inc. (Applications welcome)
Lines: 15

["The type of time_t (was: struct tm -> time_t converter wanted)"] - henry@utzoo.uucp (Henry Spencer):
) In article <9816@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
) >There's nothing to prevent time_t from being typedef'd to unsigned long int,
) >which would double the range...
) 
) Unfortunately, it would probably break a significant number of programs that
) think time_t is signed.  Those programs are arguably broken already, but some
) degree of pragmatism is necessary in such matters.

With the Epoch defined as it is for Unix (Jan 1 00:00:00, 1970), it is
desireable to have a signed `time_t' type.  Although I didn't, the world
did exist before 1970.
	Roland McGrath

roland@wheaties.ai.mit.edu, mit-eddie!wheaties.ai.mit.edu!roland