> The agency didn’t provide an estimate of how much time is currently spent on Y2K paperwork, but Linda Springer, an OMB senior adviser, acknowledged that it isn’t a lot since those requirements are already often ignored in practice.

So sure, it's good to get outdated rules off the book, but don't pretend like people were still writing reports about Y2k.

It's human nature. Nobody wants to be the one to remove a test case, procedure or process. If something goes bad shortly afterwards guess who will be to blame?

Even in software, I've seen countless man hours updating and fixing tests that were little more than "is this code what I just wrote" and many of which weren't even testing the code that was going to production.

Source?

Y2K is still an issue in some places. Without knowing more, it's possible that this could be a really bad move. Or maybe it's fine. It depends on the state of their code, which I'm not familiar with.

2050 (or whatever cutoff they're using) will suck (again) if that was their solution.

You might not care about records that are 100+ years old, but you might.

Space (both RAM and storage) is a premium on these systems and therefore much thought is given to what you place within any given row. As a result, no one stored unix timestamps as that would have required 10 characters more per timestamp per row, which would have had other ramifications on other parts of the code and/or memory. It would have required all stored records to be re-written somehow, which depending on the available online storage may have been an impossible task in and of itself. Not to mention how one would handle the recovery of any existing backups.

Due to these complexities, most organizations settled for code that shifted the meaning of the 2 digit year by some predetermined offset.