Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Oct 2001 16:51:51 -0800
From:      Peter Wemm <peter@wemm.org>
To:        Garance A Drosihn <drosih@rpi.edu>
Cc:        Julian Elischer <julian@elischer.org>, Nate Williams <nate@yogotech.com>, arch@FreeBSD.ORG
Subject:   Re: 64 bit times revisited.. 
Message-ID:  <20011030005151.CD997380A@overcee.netplex.com.au>
In-Reply-To: <p05101002b8037861a143@[128.113.24.47]> 

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011030005151.CD997380A>