Firstly: developers trying to be *too* clever are likely to only make things worse - don't do it! Whatever you do in your code, don't bodge around the 32-bit time_t problem. *Don't* store time values in weird formats, and don't assume things about it to "avoid" porting problems. These are all going to cause pain in the future as we try to fix problems. For the time being in your code, *use* time_t and expect an ABI break down the road. This is the best plan *for now*.
I find this argument unconvincing. If a library is new or is going to have an ABI break anyway then by moving to 64-bit time in it's interfaces now it can avoid another ABI break down the road. Similarly if someone is introducing a new version of a file format anyway moving to 64-bit time at the same time as making other changes avoids breaking things twice.