On Fri, 7 Jan 2000, David Schwartz wrote:
>
> > 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.)
>
Riiiight. This will not happen before 2037 unless we make changes now
that break the broken applications.
> 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)
>
The time_t interface and associated functions _are_ that API.
Any program that uses them properly would need to be recompiled on the
redefinition of time_t, but that is it.
> 3) Write all new code using the flexible API. (Starting when the API is
> done.)
>
Correct.
> 4) Cut older code that hasn't been fixed per '1' over to the new API.
>
See 3.
> 5) Enlarge 'time_t' for newly-compiled code. Try recompiling old code. See
> what breaks and fix it. (Beginning around 2025.)
>
This should be step 1.
> 6) Enlarge 'time_t' on all machines. (Around 2030 at the latest.)
>
"all machines"? Step 5 should take care of this within 5-10 years
without further intervention with certain exceptions (Xenix equivalents).
> 7) Make lots of bucks consulting about how bad the Y2.038K problem will be
> and then have it fizzle. (Starting around 2037.)
>
Make the problem go away by 2020 and have a nice relaxing 2037 developing
new stuff that we haven't even concieved yet. Fighting fires this
predictable at the last moment is no way to run a project.
-- Daniel Taylor- 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:14 EST