Well since that is in the year 2038, there isn't exactly a rush to fix it (I'd be surprised if 32-bit software/hardware is still in use by then). Something tells me it won't be an issue.
Thankfully a 64bit integer clock gets us past the year 292 billion.
That's the same reasoning everyone used for y2k. There was no way that the same software and hardware being used in 1980 would still be used in 2000... and then it was.
But the difference is we have (hopefully) learned from our y2k experience.
Also commodity hardware/software is much more common nowdays than before 2000. Back then you were reluctant to get rid of something you paid millions for because it was custom hardware running a custom OS with custom Cobol on it.
Nowdays you have commodity hardware running continuously updated OSes with custom Java on it. Thankfully Sun can update the JVM and MySQL and hopefully your date problems are solved.
If we'd truly learned something, all time values would be 64 bits. Which isn't hard: every major 32 bit systems supports 64 bit values natively in C and in only a few instructions.
Or do you mean we learned that planes won't fall out of the sky due to date problems, and we shouldn't overreact next time?
I'm quite sure that 32 bit software will be in use for a long time to come and still be in use by 2038 primarily because the ever increasing use of machine virtualization allows one to defer updating software to run on new systems. The budget conscious may ask: Why update when you have perfectly working software on a VM which can just be moved from hardware to hardware?
Thankfully a 64bit integer clock gets us past the year 292 billion.