Date: Sun, 3 Jan 1999 19:37:12 +0200 (EET) From: Narvi <narvi@haldjas.folklore.ee> To: Gary Palmer <gpalmer@FreeBSD.ORG> Cc: Jonathan Smith <jonsmith@fourier.physics.purdue.edu>, current@FreeBSD.ORG Subject: Re: Y2K, Y 2038? Message-ID: <Pine.BSF.3.96.990103192428.5112P-100000@haldjas.folklore.ee> In-Reply-To: <75916.915304507@gjp.erols.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2 Jan 1999, Gary Palmer wrote: > Jonathan Smith wrote in message ID > <Pine.BSF.3.96.990102112632.2884A-100000@fourier.physics.purdue.edu>: > > the world is freaking out over it. Perhaps an introduction of a 64 bit > > time, or larger under a different name, and have BSD start working over > > towards the new name now and deprecating the old time variable? > > While the world is still using 32bit CPUs the move to 64bit time_t will be > expensive in terms of performance. We could probably make the move on the DEC > Alpha, but until ppl move to the Merced (or whatever 64bit P.O.S. Intel > produces) I don't think many people will like to take the performance > degredation now. > Will it really? We are using 64 bit file offsets now (for a good reason, I might add), and these are definately more widely used than dates. What actually uses the date code widely? Make? > Personally, my thoughs on how to do this are to have new syscalls which return > 64 bit time_t variables, and you choose at compile time which ones you get > (i.e. sorta like the way solaris 7 has done things) > > Gary > -- > Gary Palmer FreeBSD Core Team Member > FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info > Sander There is no love, no good, no happiness and no future - all these are just illusions. 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.3.96.990103192428.5112P-100000>