Subject: Re: Y2038, was as long as we're hitting FFS...
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 03/26/1999 16:10:17
[ 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" <email@example.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 <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>