Date: Sat, 2 Jan 1999 10:39:41 -0500 (EST) From: Brian Feldman <green@unixhelp.org> To: Matt Curtin <cmcurtin@interhack.net> Cc: sporkl@ix.netcom.com, "Steven P. Donegan" <donegan@quick.net>, current@FreeBSD.ORG Subject: Re: Y2K, Y 2038? Message-ID: <Pine.BSF.4.05.9901021035130.13070-100000@janus.syracuse.net> In-Reply-To: <xlxzp81pzrp.fsf@gold.cis.ohio-state.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2 Jan 1999, Matt Curtin wrote: > Spike Gronim <spork@ix.netcom.com> writes: > > > In 2038 32 bit systems are going to run out of room to keep counting > > seconds. This is 38 years off, and will hopefully be fixed by then. > > We'll run out of seconds on 32 bit systems well before 38 years from > now. Consider that some banks are now offering 35 year mortgages, and > that it will be necessary to perform date calculations to the end of > those loans. > > The wishful thinking about it being "fixed by then" is common, but > doesn't really fly. Fixing the problem in the OS isn't a *huge* deal. > (One could change the time() to return a 64 bit value.) The result, > of course, would be dealing with all of the software that expects > time() to return a 32 bit value. At least the core system has a > finite amount of interfaces that would need to be massaged. The > random stuff floating around the Net will prove more interesting to > bring up to snuff... Trust me, we'll all be running systems of at LEAST 64-bits by then. Expecting a certain value is what time_t is for, of course needing a recompile then. > > I'm not even sure what would happen in the case of old software > compiled on a system with a 64 bit time() ... my guess is that it > would perform a typecast from 64 to 32 bits, and overflow the value > anyway. It's not a typecast, as it is runtime. If time_t is 64-bit and the system expects otherwise, look out. It can be interpreted VERY differently depening on the byte ordering of your architecture (Intel being LSB, m68k being MSB, two of the most popular 32-bit archs now). > > -- > Matt Curtin cmcurtin@interhack.net http://www.interhack.net/people/cmcurtin/ > Brian Feldman _ __ ___ ___ ___ green@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901021035130.13070-100000>