[unregistereddev]

That is not specific to 32-bit system architectures. The 2038 problem is specific to timestamps that are represented as milliseconds since the Unix epoch and are stored in a 32-bit integer. It's quite possible (and common) to deal with 64-bit integers on a 32-bit system architecture.

I am also surprised how little attention the 2038 problem gets. However, I also wonder how big a problem it is. We've known about it for years and all the software I've touched is not susceptible to it.

[listeria]

It's actually seconds since epoch, not milliseconds. Here's a small program to verify it:

  date -u --date='2038-01-19T03:14:08' +%s | perl -ne 'printf "%#x\n", $_'

It is also mentioned in perldoc Time::Piece [1], as a warning for people whose build of perl uses 32-bit integers for time.

[1]: https://perldoc.perl.org/Time::Piece#Use-of-epoch-seconds

[SAI_Peregrinus]

It got fixed in the kernel & musl in 2020. It got fixed in glibc in 2021. Everything built against the currently-supported versions of those things will have 64-bit `time_t` since the headers are updated. It mostly only matters for proprietary programs distributed only as binaries that don't get updates, for systems that no longer get updates at all, and for people running computer history museum exhibits. Some distros take a long time to update, but even the longest don't have 17-year support cycles.

I'm sure it'll cause someone some issues, but it'll be very niche by 2038. Most of the sorts of systems that it could cause problems for aren't being used to plan things years in advance, some probably don't even do anything with the date. So it's a niche within a niche (unupdatable systems used for future planning) that's likely to have problems soon, and overall probably no longer a big deal.

TL;DR: It's solved upstream, only an issue for some systems that don't get updates.