Messages in this thread | | | Date | Tue, 11 Jan 2000 05:51:34 -0800 (PST) | From | John Alvord <> | Subject | RE: time_t size: The year 2038 bug Summary: |
| |
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/
| |