There's a lot more to it than that. First, it's a matter of synchronization. Compiling a piece of software that uses 64 bit time_t and linking that (either at compile, or run time) against a library that expects 32 bit timestamps is unlikely to work correctly. Another synchronization problem happens in client/server applications. If one side starts thinking that timestamps are 8 bytes instead of 4, you have a problem. Second problem is data. 32 bit time_t date written to a database, or serialized takes 4 bytes. But if you switch to 64 bit timestamps, you can't assume your data has suddenly changed.

Now, switching to a different time_t size doesn't have to be a problem. If everyone is aware of the potential problems and takes them into account, no major problems will arrise. In fact, problems will only arrise if people are naive enough to think that "moving to a 64-bit value will make everything to continue to just work fine". It may be telling that some vendors use time64_t instead of changing the type of time_t.

Interesting is also this Long Time Type proposal.
</rant>

The answer is simply my friend. Although it could be a bit of work in some cases, its mostly considered a minor/non-issue today. Developers always have to worry about bigger problems or features to add. The closer we get, the bigger the priority this will become. Heck, we got @ 33 years to plan.

/- M a r c -/

And there you go spoiling it