Re: 1/1/1970

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Lance Kibblewhite (lance@eco.twg.com)
Date: 03/19/97-11:32:14 AM Z


Message-Id: <3.0.32.19970319093213.00907a10@vishnu.eco.twg.com>
Date: Wed, 19 Mar 1997 09:32:14 -0800
From: Lance Kibblewhite <lance@eco.twg.com>
Subject: Re: 1/1/1970 

>   >> 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.)

Faster for those systems that currently use two 32 bit values (or one for
seconds only).  But not for those (such as PC's and VMS) which already use
a 64-bit value, albeit with a different unit and base.


-- Lance


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:33 AM Z CST