> It should be noted that both approaches described above introduce zero friction to get the right thing.
If your code is called by any other code and took in a time_t recompiling would have broken your ABI.
If your code is called by any other code and took in a time_t recompiling would have broken your ABI.
I mean, waiting does mean there will be fewer 32 bit systems: so there's an argument to put off the transition to lower the scope of work.
However, most of the ones that stay around will be embedded and long-lived: just the worst kind of thing to bite us in the future.
That really highlights the benefit of the BSD model, where the OS, libc and all the base packages are shipped as a complete system. OpenBSD switch to 64 bit time_t on all supported platforms back in 2014. We all talked about Y2038 back then, and most agreed that something should be now as quickly as possible. Then the world just sort of forgot. I mean it is solved, but if you're a new developer, you might not know that you need to do something special.
The GNU and Linux world is really good at not breaking ABI compatibility and mostly that's great, but in this case it's a problem and pushing it much further is going to be a problem. It's also going to be weird if the default never change, then we just have a C library that that just keep producing defective programs, unless you add certain flags.
If you exclude like every user land library there is (including the glibc)
You can still run Linux programs linked against decades-old versions of glibc on current systems as they have kept ABI compatibility with the use of symbol versioning, without changing their SONAME ("libc.so.6").
Sure, that does not extend to being able running programs linked against new glibc symbols on old systems, but if you consider that ABI-breaking then the Linux kernel would also be ABI-breaking as you cannot run binaries relying on new kernel syscalls (etc) on older Linux kernels.