2038 is closer than it seems

Uh oh. Claiming that TIME_BITS=64 could allow a smooth transition is really wrong. The type time_t is exposed in numerous library APIs. The TIME_BITS=64 thing suggests one could mix and match components compiled with different settings freely, but that is not the case: if you compile one lib with 64bit time_t then you have to do the same for all programs using that lib. And if you do that the you transitively have to recompile all other libs they are using too, and so on. Ultimately you have to recompile the full system that way... Unless of course every single library would do what glibc does and provide both 32bit and 64bit calls for everything. And that's just not going to happen.

The same story happened for large file support (LFS) where off_t got increased in size. Now, off_t is thankfully not that often exposed in APIs, and because people knew how awful the situation was many just avoided exposing it in APIs, but for time_t the situation is much worse.

Also, one particular gem: think of stat() which already exists in two flavours, with LFS and without. Now, this API would also have to be duplicated for 32bit time_t and 64bit time_t. So you get four flavours of this call: stat(), stat64(), stat_t64() and stat64_t64()! Ouch!

And even thinking of duplicating gettimeofday() when there's also clock_gettime(CLOCK_REALTIME) is just wrong...

Lennart