5 ms·

>Seven of the more than 50 paperwork requirements the White House eliminated on Thursday dealt with the Y2K bug, according to a memo OMB released. Officials at

>Seven of the more than 50 paperwork requirements the White House eliminated on Thursday dealt with the Y2K bug, according to a memo OMB released. Officials at the agency estimate the changes could save tens of thousands of man-hours across the federal government. >“Many agencies have forgotten how to deregulate,” he said. “It’s been so long since somebody asked them to look backwards.” This is why it's generally a bad idea to make the government responsible for things that can be done by private businesses. Even the most bureaucratic corporation stopped working on the Y2K bug 17 years ago.

majewsky 9y ago
> Even the most bureaucratic corporation stopped working on the Y2K bug 17 years ago. Source?
- personjerry 9y ago
  I presume the source is that the year 2000 happened 17 years ago?
  - actsasbuffoon 9y ago
    You'd think, but I worked at a bank in the early 2000s. Some companies got lazy and shifted the problem forward a few decades rather than actually fixing the problem. 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.
    - artursapek 9y ago
      How would you "shift the problem" in this case?
      - falcolas 9y ago
        Instead of blindly assuming those two missing digits are 19, make the assumption that if they're less than 50, it's 20, and if it's greater than 50, it's 19. 2050 (or whatever cutoff they're using) will suck (again) if that was their solution.
        personjerry 9y ago
        If that's the solution, it seems like you can just make a code change every 50/100 years or so to increment the assumed century, and then this fix can work indefinitely for fairly low maintenance cost
        wickawic 9y ago
        I would be happy if my code only had a bug every 50 years.
        thaumasiotes 9y ago
        It will work for incoming data, but it will also trash all your existing records. You might not care about records that are 100+ years old, but you might.
        personjerry 9y ago
        I don't think that's an issue because I would presume you write your existing records with an absolute timestamp (unix time) rather than a relative one? Am I missing something?
        farzadb82 9y ago
        A lot of these systems were built such that date stamps were simple 6 character text fields within a larger ascii-based file format on computers build in the 60s and 70s or earlier. 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.
admax88q 9y ago
Large corporations are just as bad at "deregulating" 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.
mikeyouse 9y ago
Nobody was filing paperwork about Y2k, as is made clear by the next paragraph: > 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.

majewsky 9y ago

> Even the most bureaucratic corporation stopped working on the Y2K bug 17 years ago. Source?

personjerry 9y ago
I presume the source is that the year 2000 happened 17 years ago?
- actsasbuffoon 9y ago
  You'd think, but I worked at a bank in the early 2000s. Some companies got lazy and shifted the problem forward a few decades rather than actually fixing the problem. 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.
  - artursapek 9y ago
    How would you "shift the problem" in this case?
    - falcolas 9y ago
      Instead of blindly assuming those two missing digits are 19, make the assumption that if they're less than 50, it's 20, and if it's greater than 50, it's 19. 2050 (or whatever cutoff they're using) will suck (again) if that was their solution.
      - personjerry 9y ago
        If that's the solution, it seems like you can just make a code change every 50/100 years or so to increment the assumed century, and then this fix can work indefinitely for fairly low maintenance cost
        wickawic 9y ago
        I would be happy if my code only had a bug every 50 years.
        thaumasiotes 9y ago
        It will work for incoming data, but it will also trash all your existing records. You might not care about records that are 100+ years old, but you might.
        personjerry 9y ago
        I don't think that's an issue because I would presume you write your existing records with an absolute timestamp (unix time) rather than a relative one? Am I missing something?
        farzadb82 9y ago
        A lot of these systems were built such that date stamps were simple 6 character text fields within a larger ascii-based file format on computers build in the 60s and 70s or earlier. 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.

admax88q 9y ago

Large corporations are just as bad at "deregulating" 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.

mikeyouse 9y ago

Nobody was filing paperwork about Y2k, as is made clear by the next paragraph: > 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.