My version of Ubuntu uses long int's for time_t which are 64 bit. (see /usr/include/bits/types.h)
A 64 bit machine has nothing to do with the definition of time_t. You can run 32 bit ubuntu and you are still safe from this bug, it's just a bit slower.
Storing seconds since the epoch in a 32 bit int is fine on a Linux system because you have the source code and you can recompile if need be.
Your totally hosed on other operating systems that have a tendency to deliver binaries and keep their source code hidden. You just have to pray that the guy who made your software, recompiles the code for you and hope that it doesn't cost a lot of $ to get the new version.
ANY application on ANY os can have the problem. It's not isolated to Unix or Linux. Unix/Linux makes it easier to fix because the definition for storing seconds since epoch is in a single place. And since Unix was where time_t was first used, the bug gets named after Unix. It should really be called the ISO time_t bug, NOT the unix 2038 bug. ISO set the standard for time_t. Blame them.
Coders can still use their own 32 bit int and store epoch seconds in it. It's not good form, and very uncommon when the code is reviewed by the public. But I've seen it, I've even done it some old apps I wrote on Windows. But that code isn't around today so it's no biggy. Using seconds since epoch is very common and unless you used 64 bit datatypes to store it, you're app is hosed. It's really no different than the y2k bug; it's gonna be hyped up, lots of people will make money from the hype, lots of people will get jobs to check for bugs, and.... NOTHING will happen.
People in the Open Source camp don't have to worry about anything. Binary folks sure do.
I've never flown. Maybe one day when all the hardware/software in the vehicle is open source I'll try it.
http://rss.slashdot.org/~r/Slashdot/slashdot/~3/202963032/article.pl
Grats Mop on fixing the URL bug. ;-)