In the coming years, there will be other time rollovers beyond Y2K. The next big one isn't all that far away.
Contrary to what you might have heard, the reason more computers didn't break on Jan 1st 2000 wasn't because it was a false alarm. It was because massive resources were poured into avoiding many of the problems. And many things did in fact break, but backup plans were in place. (I recall not getting financial reports for most of 2000 for my spending accounts at work. So I had to keep my own books and hope I didn't overspend -- because the old accounting system expired at the end of 1999 and the new one wasn't on-line until Fall 2000.)
In January 2021 we saw some aftershocks when a 2-year time digit window hack ran out of steam from Y2K patches. But the world didn't come to an end.
The next potentially huge time problem will be January 2038 when the 32-bit signed Unix time in seconds rolls over.
Plenty of embedded systems last 20+ years (already we are closer than that to 2038). Plenty of embedded systems are using 32-bit Unix, since 64-bit CPUs just cost too much for the proverbial toaster oven. An increasing number of systems are updatable, but many require manual intervention. Updating your DVD player (if we still have them in 2038) won't be so bad. Updating a natural gas pipeline valve in the middle of nowhere -- not as fun. Updating all your smart light bulbs will range from tedious to buying all new lightbulbs. And so on.
This is a good time for embedded system designers to decide what their game plan is for Y2038. As your expected product life starts overlapping with that (as I write this, it's only 17 years away), you're accumulating technical debt that will come due in a big chunk that year. Better to have a plan now than a panic later. Later has a way of sneaking up on you when you're not looking.
For a more detailed list of timer rollover issues, see:
