...This resulted in the service generating an invalid x509 certificate [but fortunately the validation library said that the cert was invalid, just didn't tell me why] -- making me lose a day to debugging this mistake.
Somebody should standardize an x.509.good_parts subset that leaves out all the crap nobody needs and doesn't work anyway in deployed systems.
In another 78 years they can make it a little smarter.
openssl x509 -req -days 7000 -in site.csr -signkey site.key -out site.crt
Lots of software on 32-bit Linux systems will choke on it when the experation date crosses 2038, albeit not major web browser as they saw the issue early on and addressed it.Usually, any product sold comes with 2- or 5-year warranty if your lucky.
Some RAM manufacturers were so proud of their manufacturing quality, they instead offered 50-year warranties.
Now, the reasonable thing to do as a seller would have been to just limit that to something like 5 years, and then give the customer their money back if they had any issues after that.
However, someone actually programmed the system to use 50 years as the warranty duration, way in the 2040s.
I didn't look further into the technical issues behind that (probably not many, since the required precision wasn't seconds, just days), but that remains a great example of when not building a feature costs less than building it.
Keeping in mind that XFS is a filesystem format, it's not hard at all to imagine a filesystem created in CentOS 8 and/or RHEL 8 still being in use when 2038 arrives, even if the operating system was already upgraded to the next major version.
It's not - it'll be here before you know it.