Date: 02 Jan 1999 08:31:22 -0500 From: Matt Curtin <cmcurtin@interhack.net> To: sporkl@ix.netcom.com Cc: "Steven P. Donegan" <donegan@quick.net>, current@FreeBSD.ORG Subject: Re: Y2K, Y 2038? Message-ID: <xlxzp81pzrp.fsf@gold.cis.ohio-state.edu> In-Reply-To: Spike Gronim's message of "Fri, 1 Jan 1999 18:53:52 -0500 (EST)" References: <Pine.BSF.4.05.9901011850130.10809-100000@nyc-ny73-44.ix.netcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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... 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. -- Matt Curtin cmcurtin@interhack.net http://www.interhack.net/people/cmcurtin/ 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?xlxzp81pzrp.fsf>
