True. But I wouldn’t see this as extremely more critical than the hundreds of other issues we encounter daily in software. Tbh, I’d be glad if some of the software I have to use daily had more duct tape on it…

I would hope that these kinds of parsers are not used in critical applications that could actually lead to catastrophic events, that’s definitely different to Y2K. There would be bugs, yes, but quite fixable ones.

Regarding Y2K, it wasn’t horse shit - thousands upon thousands of developer hours were invested to prevent these issues before they occurred. Had they not done so, a bunch of systems would have broken, because parsing time isn’t just about displaying 19 or 20.

“There’s no glory in prevention”. I guess it’s hard to grasp nowadays, that mankind at some point actually tried to stop catastrophies from happening and succeeded

Y2K was definitely not only fear-mongering. Windows Systems did not use Unix timestamps, many embedded systems didn’t either, COBOL didn’t either. So your explanation isn’t relevant to this problem specifically and these systems were absolutely affected by Y2K because they stored time differently. The reason we didn’t have a catastrophic event was the preventative actions taken.

Nowadays you’re right, there will be no Y10K problem mainly because storage is not an issue as it was in the 60s and 70s when the affected systems were designed. Back then every bit of storage was precious and therefore omitted when not necessary. Nowadays, there’s no issue even for embedded systems to set aside 64 bit for timekeeping which moves the problem to 292277026596-12-04 15:30:08 UTC (with one second precision) and by then we just add another bit to double the length or are dead because the sun exploded.