From: Mike Eisler (mre@jurassic.eng.sun.com)
Date: 03/18/97-04:05:22 PM Z
Date: Tue, 18 Mar 1997 14:05:22 -0800 (PST) From: Mike Eisler <mre@jurassic.eng.sun.com> Subject: Re: 1/1/1970 Message-ID: <Roam 0.9.4.858722722.13317.mre@jurassic.eng.sun.com> > > >> If 2106 is too soon, then why not change the format from two 32 bit > value > s > >> to a single 64 unsigned value. With a 1970 base, this then ranges out > to > >> around 2554. > > > >Interesting idea, though doesn't this burden OS's or filesystems > >that do not support time resolutions below 1 second ? Currently > >they can just plug in the seconds value and set the nanoseconds > >to zero. If the entire value is represented as 64 bit nanoseconds > >then they'll required to do some non-trivial 64 bit arithmetic. > > Another possibility (that doesn't even need to be part of NFS V4) is to > store the high two bits of a 34 bit seconds value in the high two bits of > the nanoseconds. Reassembling the data would be faster than the divide > Lance is suggesting. Of course, no one would bother to implement it until > the year 2100. (Which, of course, is *not* a leap year, but that's a topic > for a different forum.) I like this. We could use one of the spare bits as a sign bit giving us an approximate range of 1697 - 2242 A.D. Not good enough for physicists that want to use O/S file times, but certainly adequate for commodity futures and banks and some historical applications. As Rick says, no one would bother to implement it for some# of years (I would hope someone would try it some time before 2038), but it gives our successors plenty of time to figure out what V5 should be. -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:33 AM Z CST