It's more damaging than the Y2K bug. That's because Y2K mostly involved
higher-level applications such as credit card payment and inventory
management. The 2038 bug, on the other hand, affects the basic
time-keeping function.
As said by Rik, it is not an issue on 64 bits machines.
Also, if we redefine time_t as a 64 bits value even on 32 bits machines, and recompile all applications and libraries, I suspect it will works in most cases if the programs can already run properly on 64bits architectures. Thought it will probably run slower in many cases.
I don't think we would have a lot of checking to do to be sure that the kernel and libraries for the differents architectures handle this correctly.
The applications that will creates problems are thoses that are saving the data in an architecture dependent way (we will have to convert the format). Or thoses that cast time_t to a 32 bit variable. But thoses systems probably already have problems running on 64bits machines, or communicating with them by the network.
Still, in 30 years I can easilly imagine 128 bits computers at the local shop. And pretty much all systems that we will care about will be at least 64 bits machines (many important systems already are since a while).
So no, it will definitelly be a minor issue compared to what it was on Windows.
Simon Valiquette
-- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
