[ On Thursday, March 25, 1999 at 12:07:16 (-0800), Jason Thorpe wrote: ]
> Subject: Re: Y2038, was as long as we're hitting FFS... 
>
> On 25 Mar 1999 14:48:58 -0500 
>  "Perry E. Metzger" <perry@piermont.com> wrote:
>  > 
>  > Or we could do another gross hack that is even less intrusive.
>  > 
>  > If we declare the times in seconds in the inodes to be UNSIGNED, we
>  > gain another 68 years.
> 
> ...but you still have to version the inode.

I don't think so.

If you go back to kre's recollections of changing time_t to unsigned
(1998/06/03 tech-userlevel, "signed vs unsigned time_t") you'll find
that the only obvious problem found at the time was how to generate a
representation of zero in some more human acceptable format.  If you fix
that then the entire system can change to use an u_int32_t for time_t
and no versioning is necessary anywhere but in the shared libc.  I'd be
extremely surprised if anything in the kernel actually relied on having
negative values for time_t, and wasn't a bug in the first place.

I think it would be best for the library routines to treat zero as an
illegal value and not try to generate any representation in the local
timezone -- generate something that indicates the timestamp is unset or
illegal instead.  Of course its not too hard to get the arithemetic
right such that no change would be visible either.

I also think it's much easier to find the possible corner cases for
using a signed time_t than it is to change the width of time_t.

I note though that Steve Summit claims some Unix implementations
(presumably DU) are already successfully using 64-bit time_t.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>