Re: Summary of the 2038 BoF at DC17
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
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.