Yep. I broke a system at work this way. I needed a piece of crytopgraphic information generated by an internal system for testing. The system requires all pieces are signed (with an accompanying expiration date). I decided to ask for it to be signed for 100 years.

...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.

The real mistake was wanting a certificate life longer than the expected time to crack it.

For test systems? Unless you are testing key rotation, who cares?

Point taken. The certificate generator program should have reported the error. Everything connected with x.509 barely works.

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.

For systems that are infrequently (or sometimes, never) updated, you might want to sign firmware images for as long as possible to ensure the devices can (a) support signed updates from the OEM; and (b) can work indefinitely even if the OEM disappears.

I used to work at an online shop that among other things, sold RAM.

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.

The NTP epoch rolls over in 2036. My guess is that a lot of embedded devices are going to fail without warning.

I started hitting issues quite some time ago. Such as generating long-term self-signed certificates for internal services.

  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.

I routinely have nightmares about this for many of the systems I code for now.

Start coding wrap checking that replaces a negative number with the corresponding correct time.

In another 78 years they can make it a little smarter.