Re: Y2K+38 disaster in debian?
Quoting Stephen J. Carpenter (sjc@delphi.com):
> On Wed, Sep 30, 1998 at 11:01:22AM -0400, Michael Stone wrote:
> > 2) 64 bit math is _very_ slow on a 32 bit machine. Since time_t is used
> > all over the place (e.g., the filesystem) you'd seriously slow things
> > down by making it 64 bits.
>
> Well heres an idea...
> Currently time_t only USES 31 bits. Why? because it is signed!
> if we were to make time_t unsigned then it would double the amount of
> available time till the overflow
> (by double I mean double from the epoch. that would mean 2038 ius the
> halfway point... which gives us another 69 years after 2038...or
> 2107)
>
> of course the ramifications of this would need to be tested...
> hmm... wish I had a spare machine to try it on
You could get some pretty interesting results from subtracting dates if
you did this. A signed number wasn't chosen just to waste space.
> > 3) Since 64 bit archs already use a 64 bit time_t, this is a problem
> > that will go away when 32 bit machines are phased out (I can't see most
> > hardware lasting forty years.)
>
> I agree...but...they still could be.
If you're using a pentium-class machine in 2038, you deserve what you
get. I can't believe it would be operative after that long.
> Isn't that exactly what the people who
> were writting mainframe applications a few yars ago said? :)
>
> "Nah this system wont be in use past 93 forget about 99"
Not exactly. Migrating the time_t is just a matter of recompiling an
app. (Unless your app was written badly in the first place.) You can
test that migration today by running your app on a 64 bit machine like
an alpha. The y2k problems are largely caused by existing data and by
inadequate _program specific_ data representations. If your program uses
a proprietary representation, it will need to be rewritten; if your
program uses time_t, it needs a recompile with a new libc. And as I said
before, if your data is stored as a time_t, you _already_ have problems
because that's not a portable solution.
mike stone
Reply to: