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 much about 32-bit architectures. For Fedora, that would affect the i686 architecture only. Given that i686 is kept around mainly for legacy applications these days, without a kernel and installation media, I expect that Fedora prefers compatibility with 32-bit time_t applications. The latest proposal (64-bit time_t only for new applications) would therefore be problematic to Fedora.