RE: time_t size: The year 2038 bug?

From: Magnus Danielson (cfmd@swipnet.se)
Date: Thu Jan 06 2000 - 09:01:43 EST


From: "Jakma, Paul" <Paul.Jakma@compaq.com>
Subject: RE: time_t size: The year 2038 bug?
Date: Thu, 6 Jan 2000 12:29:42 -0000

>
> > Noone uses old machines for very long. How many of you are
> > still using a
> > PDP-10 (30+ years ago) or an Apple classic (20- years ago) for "real"
> > work?
>
> Compaq still support PDP's because they are still in active use. I know of
> sites that still run PDP-11's!!
>
> We were selling *new* microVAXen up until Nov '99!!
>
> So I guarantee you that in 2038 there will still be plenty of 32-bit
> hardware in active use. Certainly enough to make time_t be a problem. (just
> think of embedded systems).

This is the whole trouble of Year XXXX related problems. While you very well
have had time killing the bulk of old hardware off, there are still the residue
that sits all over the place and replacing them hurts seriously in time, money
and man-power. So these things will not be killed of regardless of how broken
it migth be to our hacker nature. We better face facts and come up with a
solution for the 2038 problem at least. If we can solve Y10k while we are at
it (it takes only a few bits) we should consider doing it.
By going from signed to unsigned we at least move the deadline another 70 years
ahead and this migth be sufficient for the meanwhile. Also, I think that this
is the most probable thing to happend in the UNIX world. It would be better if
we fixed some better margin thougth, but many would call that overkill.

Besides, I have yeat to understand what application that would take a high
preformance kill by having to deal with 64 bit time instead of 32 bit time.
Yes, for todays computers it is extra overhead, but not at all at the scale
that when counting all the other zillions of operations normally done it would
really cause a break-or-make case.

Actually fixing broken protocols and software is certainly an issue. In order
to solve that one can't do a single step change, but has to migrate things over
one by one. This calls for means of coexistence. Maybe some new time_t with
a diffrent format and libc support added to use that and convert between the
formats. It's ugly and not very neat, but less will break directly and you get
the chance to fix it.

So, sadly enougth will good designs doing what they where designed to do keep
on working despite the limits of the design that was acceptable at the time of
the design. This is the trouble of life and we have to face that fact.

Linux can be made to be very stable and thus we no longer can make accurate
estimates for how long it can live and keep working in some suitable
environment.

Cheers,
Magnus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:06 EST