The thing is, 2038 is less and less far away with each day that goes by. Especially since real programs often have to use future timevalues (and often further in the future than one would think).
Stuff has to change at some point. A glibc major version which changes the structures and typedefs for all 32 bit code could handle it.
But as it stands now, someone who wants to make a 32 bit program y2038-compliant will have a hard time doing it: they can't safely hand time values to any library that is possibly compiled differently.
This punts it to whom, distro maintainers? They have to try and rebuild everything with the correct define? And the lone end-user who does gcc -o myfile myfile.c gets code that's broken against the system libraries? Or they patch glibc itself and ship a glibc that's ABI incompatible with everyone else. Meh.
Either glibc will do it, or time itself will do it. But when time will do it, it will be much harder breakage.
* https://www.gnu.org/software/libc/
Change the default and release "3.0" with the time_t alteration at the top of the ChangeLog. 2.x can perhaps live for a while for some overlap.
The distros will eventually pick it up, and all code compiled/released for a particular distro version will deal with it in course.