The problem is in applications
As already mentioned, this has already been corrected in the Linux kernel itself for 64 bit versions, and 32 bit hardware is fading from the scene rapidly. The ext3 file system which was mentioned has been obsolete for some time, having been replaced by ext4, which itself by the way is on the way to being replaced by its own successor. There probably aren't a lot of ext3 systems around even today.
The real problem however is with application software. A new 64 bit time has been provided, but that doesn't patch existing applications. The old 32 bit time is still there for backwards compatibility. The problem is going to be what to do about software that doesn't get upgraded to use the new 64 bit time interface.
I haven't heard Corbet's recent talk, but previously he was writing about the pros and cons of trying to find some way to change the older 32 bit time value without breaking too many existing applications. In other words, to somehow give those apps an automatic upgrade. Various ideas have been discussed, but nobody feels confident enough to simply go ahead and do any of them.
If there was only open source/free software to worry about, we could scan the source code of all the common software for 32 bit times and to patch the software to use 64 bits. However, there is also a lot of existing proprietary software out there where that is not an option. Customers have running code which may not be maintained anymore by the vendor, but it is running (for now) and there is a strong reluctance among Linux developers to do anything which might cause problems for them.
A creative solution may be found, or alternatively the answer might be to tell people to suck it up and upgrade their software to 64 bit values some time before 2038. It's a matter of balancing the relative risks. The big problem of course is going to be with the "never, ever, ever, upgrade" crowd who aren't going to apply either sort of solution.
The problem by the way isn't limited to unix-like systems. Back in 1999 I was working on finding and fixing the Y2K problems in industrial machinery for a large global manufacturing company, and there were 2038 roll-over issues with 8 bit industrial controllers which were made by one of the largest companies in the business. There was no unix/Linux/whatever OS involved. The software was running on the bare metal. The system designer just happened to use the same date epoch and date size. I noticed that, but put the issue aside as not being relevant to Y2K (I found good solutions to all the Y2K issues elsewhere though).
I expect there are loads of other embedded systems out there which are similar. It's a general issue industry wide.
I also wouldn't count on Windows systems being immune to this issue. As noted above, the issue isn't with the Linux kernel itself, where the problem is already fixed for 64 bit. The real problem is with application software and third party libraries. There are plenty of those around which might be doing date handling in ways which produce unexpected results regardless of how the OS itself handles dates.