There is an effort under way to enhance glibc so that it can use the Y2038 support in the kernel. The result will be that more 32-bit architectures can use a 64-bit time_t. (Currently, it's x86-64 x32 only.)
Originally, the plan was to support both ABIs in glibc for building new applications, similar to what is currently possible with -D_FILE_OFFSET_BITS=64 for changing the size of off_t. However, this turned out to be difficult to implement, and so far, no one has posted patches which appear to be reasonably correct and complete. The latest proposal is a single-ABI mode for development: <https://sourceware.org/ml/libc-alpha/2019-07/msg00433.html> Old binaries with a 32-bit time_t will continue to run, but new binaries built against a current glibc will always use a 64-bit time_t under this approach. The consequence is that in order to build 32-bit-time_t libraries (Gtk, for example), an old glibc needs to be kept around. In practice, it would probably mean that it is impossible to maintain a set of 32-bit-time_t libraries in a classic distribution build environment (with a unified buildroot and native builds). I do not have a strong opinion about this because I personally do not care about 32-bit architectures at all (sorry). I would like to solicit Debian's feedback on this matter. Do you want to build 32-bit libraries (besides glibc) which are compatible with legacy applications, with a 32-bit time_t, in the future? Or is a world where time_t is pretty much always 64 bit something that would be acceptable?
