From owner-freebsd-arch Mon Oct 29 16:52: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 7558537B405 for ; Mon, 29 Oct 2001 16:51:52 -0800 (PST) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9U0pqM59868 for ; Mon, 29 Oct 2001 16:51:52 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id CD997380A; Mon, 29 Oct 2001 16:51:51 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garance A Drosihn Cc: Julian Elischer , Nate Williams , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: Date: Mon, 29 Oct 2001 16:51:51 -0800 From: Peter Wemm Message-Id: <20011030005151.CD997380A@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > At 12:46 PM -0800 10/29/01, Julian Elischer wrote: > >why? > > You are coming up with a method to expand timestamps to the year > 2600, and the proposal works by stealing bits from one place and > adding that to unsigned bits in another. I can not imagine 400 > years of looking at such a baroque kludge, so I also say "yuck". > > We can fix time_t to hold 64-bit values. Kirk McKusick has already > said that he's working on an upgrade for UFS which will simply store > those 64-bit values as 64-bit values. I would rather see energy > spent on that solution instead of piecing together a value from > various bits which are theoretically available. If we get so UFS2 > has basically replaced UFS by (say) 2010, then we'll be in fine > shape and in plenty of time. > > That is just my opinion, of course. And it is quite valid. There is NO NEED to tweak UFS for timestamps. It will be good right up till 2038 if we're still using it instead of UFS2 or UFS3 or whatever. UFS does not have future dates and does not do future date calculations. We could probably even change the ufs_time_t to unsigned and string it out to 2106 or so if we really wanted to stretch it out beyond reason. Repeat: there is no point "fixing" the ufs timestamps. UFS2 will take care of it. > >On Mon, 29 Oct 2001, Nate Williams wrote: > > > >> > yes you are right here.. > >> > > > > > But the two TOP bits of the nanosecond fields are by definition > > > > always 0 (you can only have up to 1,000,000,000 nano seconds in > > > > a partial second) and 32 bits goes up to 4 (American)billion, so > > > > the two top bits can safely be used for multiplying the seconds > > > > scale by 4. ... timestamps can't be before 1970 so making it > > > > unsigned allows us to go to 2100+ and mutiplying it by four takes > > > > us to about 2600.. > > > > > > All I can say is *yuck*. > > -- > Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu > Senior Systems Programmer or gad@freebsd.org > Rensselaer Polytechnic Institute or drosih@rpi.edu > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message