In the protocol there are multiple timestamp fields with varying lengths. For example a 4 byte unix timestamp would overflow in the year 2106. Will a hard fork be needed to deal with this issue in the coming century?
There is a fairly trivial solution, which is technically a hard fork, but doesn't require changing fields.
The idea is that the timestamp is indeed treated as a 64-bit value, but only its lower 32 bits (which are then allowed to overflow) are stored in the block header. When a block's 32-bit timestamp is sufficiently much lower than the previous blocks' 32-bit timestamp, it is assumed to have overflowed, and 2^32 is added to the interpreted 64-bit timestamp.