> On Fri, 7 Jan 2000, David Schwartz wrote:
> > 2) Add support for a flexible time API to the kernel and
> > libc. This API,
> > and code 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.
The problem is that too much code makes assumptions about the structure of
'time_t'. If we're going to change that structure, we're going to break
things. So we'd either have to break current code, wait until everything
else is fixed to change it, or replace it with a new API. I strongly prefer
the third option.
> > 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.
It can't be. As soon as we enlarge 'time_t', non-compliant code will break.
There's too much non-compliant code out there. I don't want to wait until
all the non-compliant code is fixed to begin working on the problem. And I
don't want to needlessly break code today that would work fine for 30+
years.
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:14 EST