On Fri, 7 Jan 2000, David Schwartz wrote:
>> fix itself? It sounds like it is both a kernel and a libc issue.
>> It also
>> seems to me that the easiest thing is to go to 64 bits.
>>
>> I am not doing libc or kernel development, so I don't believe I can
>> own this one, though I am open to suggestions-any takers?
>> -Doug
>
> I think you missed the part about how fixing this in the kernel and in libc
>will break an awful lot of code that currently works. It's an application
>issue as much as it's a libc issue.
>
> I think the best plan so far is to (with approximate timeframes):
>
> 1) Fix application code that makes assumptions about time_t. (Starting now,
>ideally finish within 15 years.)
And in the mean time, just as many new applications will come
along, both open and closed source that use time_t as it is now,
and after 15 years we will have just as many problems anyways.
You can't beam the Y2038 time_t "don't do this" solution into
every programmer's head simultaneously. Saying "well it is their
fault for not following our recommendations" is also fruitless
because the goal is to not have computer problems, and casting
blame after the fact, does not solve the problem.
> 2) Add support for a flexible time API to the kernel and libc. This API,
>and could that uses it, should remain Y2.038K-compliant without a recompile.
>(Design now, start coding in 2-3 years, ideally standardize within 10 years
>and apply across most platforms within 20 years)
Now that is a fairly good idea I think. Database data however
that is non-compliant now will need to be fixed, as well the
software that accesses that data.
> 3) Write all new code using the flexible API. (Starting when the API is
>done.)
>
> 4) Cut older code that hasn't been fixed per '1' over to the new API.
>
> 5) Enlarge 'time_t' for newly-compiled code. Try recompiling old code. See
>what breaks and fix it. (Beginning around 2025.)
Again, what about databases? The data inside them that is, that
is stored as 32bit int? Now it must be 64bit. Database
conversion software needs to be written.
> 6) Enlarge 'time_t' on all machines. (Around 2030 at the latest.)
I think that is way way too long.
> 7) Make lots of bucks consulting about how bad the Y2.038K problem will be
>and then have it fizzle. (Starting around 2037.)
Personally, I think the same fiasco that happened for Y2K will
again repeat in 2038. People will leave it to the last possible
second and then rush to try and fix the problem. If they do as
good as Y2K allegedly "seems" to have done (only time will tell)
then we won't have a problem. ;o)
TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocateJoin the FreeMWare project - the goal to produce a FREE program in which you can run Windows 95/98/NT, and other operating systems.
- 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 : Sat Jan 15 2000 - 21:00:16 EST