> That said, how do we fix it? Or is it something we just believe will
> 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.)
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)
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.)
6) Enlarge 'time_t' on all machines. (Around 2030 at the latest.)
7) Make lots of bucks consulting about how bad the Y2.038K problem will be
and then have it fizzle. (Starting around 2037.)
DS
-
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:11 EST