[lkml]   [2000]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: time_t size: The year 2038 bug Summary:

> 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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.156 / U:0.064 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site