RE: Y2K+38 disaster in debian?
I think folks are giving too much credit to 64bit architecture
hardware. time_t is still 32 bits on dec alpha (dec unix 4.0b).
...
/*
* test time_t
*/
#include <time.h>
#include <stdio.h>
void main (void)
{
printf ("size of time_t is: %d\n", sizeof (time_t));
}
$cc -std1 junk.c
$a.out
size of time_t is: 4
If 64bit integer math is too slow, you could always use double.
You wouldn't loose too many billion years resolution...
jim
----------
From: Michael Stone[SMTP:mstone@itri.loyola.edu]
Sent: Wednesday, September 30, 1998 11:55 AM
To: debian-user@lists.debian.org
Cc: The recipient's address is unknown.
Subject: 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
--
Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
Reply to: