A) will be fine until 2038. I assume we have a lot of things that mashes time into an int or long. But such code is no worse off by virtue of the C library types being fixed.
B) -- manual calculation of size of structs instead of sizeof() -- yah, maybe it'll happen. I don't see much code this bad. If it's ever compiled on a different word length it's already been fixed.
C) Perhaps. For the most part alignment improves when you have a wider time_t, but you could have people counting the number of 32 bit fields and then needing 16 byte alignment for SSE later. Again, for the most part this penalty has been paid by code compiling on amd64, etc.
Wouldn’t it also fail for all code that
a) stores the return value in a plain int and not a time_t as it would truncate (but at least this is a warning)
b) has time_t inside struts and allocates their size or arrays of structs assuming time_t is 4 bytes
c) has time_t inside structs and assumes the byte alignment of fields following it
Etc etc..