On Mon, 10 Jan 2000, David Schwartz wrote:
>
> > This is my point.
> > To plan that (probably someone else) will perform a critical
> > fix in 25 years is ludicrous. The fix needs to be performed ASAP,
> > so that userspace developers with broken code will have to
> > fix it NOW, not in 25-30 years.
>
> This argument would have resulted in a massive cutback in the number of
> horse-drawn carriages allowed in London in 1900, on fear that the streets
> would be filled with horse-poop in 2000. It's as ridiculous then as it is
> now.
>
> You want to postpone the pain as long as possible, for when the tools will
> be there to fix it right.
>
> You make a measured schedule that will solve the problem before it's real,
> and you adjust the schedule as technology advances. To try to solve 2038's
> problems with 2000's technology is idiotic. You will undergo much pain for
> solutions that probably won't even be in use in 2038.
Rather then change the meaning of time_t, why not define an new value of
epoch_t which is currently zero. That way software can be converted
gradually and old software will continue to work unchanged. The
infrastructure will use the epoch_t value to do things the right way.
Given the recent Y2K scare, getting a label that says your software is
2038 compliant should be powerful marketting material in 10-15 years.
john
-
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:17 EST