back to article Yeah, if you could just stop writing those Y2K compliance reports, that would be great

The US Office of Management and Budget (OMB) has announced rule changes that – among other things – will finally end the requirement that agency IT departments report their Y2K compliance, only almost two decades after the event. A memo [PDF] published by the White House lays out a set of rollbacks to the reporting …

  1. Steve Davies 3 Silver badge
    Alert

    Replace Y2K with PTSD

    Post Trump Systems Disaster

    Groan.

    1. This post has been deleted by its author

    2. NoneSuch Silver badge
      Pint

      Best Job Ever

      This reminded me of a job I saw in 1999. Was a 6 month contract worth $120,000 for a Y2K IT specialist to oversee corporate preparations for the New Year.

      Contract end date was December 31st, 1999

      I didn't apply as I'd just started a new job, but man was I tempted to get that easy money.

  2. nagyeger

    Just in time for 2038

    If this law's been around 2 decades, does that mean it's about time for for unix "end of time" compliance reporting to start up?

    We must be getting into the era when hardware (IoT?) is going to last long enough that this is a problem.

  3. MacroRodent
    Alert

    Time for Y2.1K

    2100 is in only 83 years, you know, I'm pretty sure some systems deployed now will still be in use then, unless our technological society collapses before.

    1. DontFeedTheTrolls
      Boffin

      Re: Time for Y2.1K

      I'm guessing you're not old enough to understand what the crux of the problem was.

      History lesson. Back in the old days when memory space was very expensive developers saved memory by coding the year in two digits, This worked well in the 60's and 70's, but by the time the 90's came along many people realised all sorts of odd things could happen when the date ticked over from 99 to 00.

      2099 to 2100 shouldn't be an issue

      1. MacroRodent

        Re: Time for Y2.1K

        >I'm guessing you're not old enough to understand what the crux of the problem was.

        Actually, I am, even fixed a couple of minor Y2K bugs back then. And after Y2K, I have seen applications again start assuming 2-digit years, just for convenience, only difference being they are now 20xx dates. Memory usage isn't really the problem, but the laziness of developers and users...

        Besides, many Y2K fixes were really hacks that assumed 20xx after some cut-off year. They run into trouble even before 2100!

        1. allthecoolshortnamesweretaken

          Re: Time for Y2.1K

          "Besides, many Y2K fixes were really hacks that assumed 20xx after some cut-off year. They run into trouble even before 2100!"

          Yes, I vaguely remember that there were fixes on some systems that were more like somewhat questionable workarounds that pushed the problem from 1999 to 2019; the thinking being "that will give us enough time to either fix the problem or replace the systems completely". Well, time's nearly up - does anybody know whether this is still an issue?

      2. Dan 55 Silver badge
        Happy

        Re: Time for Y2.1K

        2099 to 2100 shouldn't be an issue

        Pfff... Many Y2K fixes just changed the window in which two digits were mapped onto four.

        And the current crop of young whippersnappers seem only to keen to make the same mistakes all over again.

        And I bet FAT32 will still be around because nobody seems willing to be the first to move to something sensible like UDF. And FAT32's maximum year? Yes, 2099.

        1. DJV Silver badge

          Re: Time for Y2.1K

          Is it too early to start worrying about the Y10K problem?

        2. Wensleydale Cheese

          2 digit years and 2030 in LibreOffice spreadsheets

          "Pfff... Many Y2K fixes just changed the window in which two digits were mapped onto four."

          It's still there in spreadsheet programs if you enter years as 2 digits.

          The default in the current version of LibreOffice is to treat 2 digit year inputs as values between 1930 and 2029. See Options/Preferences -> General for that setting.

          (I don't have a copy of Excel handy at the moment, so sorry, I can't check that)

          There are still a lot of systems which use 2 digit years in output logs or CSV equivalents. Guess what happens when you import them into spreadsheets?

      3. John Brown (no body) Silver badge

        Re: Time for Y2.1K

        "This worked well in the 60's and 70's, but by the time the 90's came along many people realised all sorts of odd things could happen when the date ticked over from 99 to 00."

        FYI, many people were aware of the issue as early as the 70's and earlier. Pensions, mortgages etc doing valuations many years into the future, long term payment schedules etc. It wasn't generally considered, but there people and industries affected and thinking about long before the BBC told Joe Public there would an ITpocalypse!

      4. Anonymous Coward
        Anonymous Coward

        Re: Time for Y2.1K

        Whilst many people did get it some were not so smart. I had a developer working for me who wrote code in September 1999 with a Y2K bug in it! Never underestimate people's capacity for incompetence. Fortunately he wasn't working for me by the end of that year.

        I also had a manager who was very smart but hadn't quite grasped the subtleties of what day followed February 28th 2000. As we discussed potential Y2K issues and briefly argued about the leap year he realized that code he had written a few years earlier was going to break. Not incompetence in his case, just a simple miscomprehension of the facts.

        1. Jeffrey Nonken

          Re: Time for Y2.1K

          Yup. Y2k, while definitely a problem, was far too over-hyped. Two months later there was a massive scramble when people were blindsided by the 2000 Leap Year bug. :)

          FTR, though, microwave ovens continued to heat food and airplanes continued not to fall out of the sky.

    2. Prst. V.Jeltz Silver badge

      Re: Time for Y2.1K

      "unless our technological society collapses before."

      thats a pretty safe bet in my opinion

  4. John Smith 19 Gold badge
    Unhappy

    I guess it'll depend how people "fixed" their problem

    Some solutions will be OK until the date length needs to expand to 5 digits, and barring really major improvements in healthcare I doubt any of us will be around (in any form) for that event.

    Of course those who used some quick & dirty flag to fix it may have a bit more of a problem.

    1. Anonymous Coward Silver badge
      Mushroom

      Re: I guess it'll depend how people "fixed" their problem

      5 digits, no.

      33 bits however... Y2K38 is coming

      1. Arthur the cat Silver badge

        Re: I guess it'll depend how people "fixed" their problem

        33 bits however... Y2K38 is coming

        Actually it's 32 bits that's the problem. Roll over into the top bit of a signed time value. Even if the OS is 64 bit there will be file systems or data formats that use 32 bit time values. For some cases treating the value as unsigned kicks the problem 68 years down the road, but for anything using historical data before 1970 that's not possible.

        1. Wensleydale Cheese

          Y2K38 is coming

          Potentially already bust by that 25 year mortgage projection...

      2. bombastic bob Silver badge
        Devil

        Re: I guess it'll depend how people "fixed" their problem

        33 bits from "the epoch", fixed already in more recent Linux and BSD kernels. Unless you have a 30 year old wifi router...

        1. katrinab Silver badge

          Re: I guess it'll depend how people "fixed" their problem

          Does your wifi router care about the date? Have you ever checked it to ensure it is accurate?

          1. Dan 55 Silver badge

            Re: I guess it'll depend how people "fixed" their problem

            I should hope so, DHCP needs the timezone to be right...

  5. RealBigAl

    Ah Y2K, We had one then senior manager at the time demanding to know what we'd do to ensure the problem didn't re-occur when systems had to deal with the switch to five or six digits. We assured him it wasn't something he needed to worry about....

    1. gv
      Pint

      Famous last words when that critical banking COBOL batch program crashes in the year 10000.

      1. stephanh

        Well, somebody will have to worry about it, but it is unlikely to be *him*.

        I am quite certain COBOL will still be around in y10k. Not so sure about the human race.

        1. John Smith 19 Gold badge
          Joke

          "I am quite certain COBOL will still be around in y10k."

          I have a possible defense.

          PHB "I see from our records Mr Smith that you did the last year mods on this program and we've confirmed you were the John Smith on the change log."

          Me:" I could only afford the low res brain scan for my personality recording and they may have missed a few things. What's a COBOL developer?"

          PHB "The computer language, COBOL."

          Me."No, I mean what's a developer?"

      2. gannett

        COBOL has been a fossil since 1980 at least and that's over a working lifetime ago.

        1. stephanh

          Cobol a fossil?

          Then it is what biologists would call a "living fossil".

          1. Scroticus Canis
            Holmes

            Re: Cobol a fossil? Bet it's around longer than Cher or the cockroaches

            I was still teaching COBOL in the '90s, OK mostly to big corporation staff, but I bet much of that code is still running in a lot of Unix VMs emulating an old IBM or ICL mainframe runtime environment.

        2. Jeffrey Nonken

          "COBOL has been a fossil since 1980 at least and that's over a working lifetime ago."

          And yet here I am, not yet at retirement age, nor even yet officially considered a senior citizen. At least not by U.S. standards. I started working in 1975, I'm only 60, so you're off by at least a decade.

          Not that I am interested in retiring at 65, but just using that as a standard.

        3. John Smith 19 Gold badge
          Coat

          "COBOL has been a fossil since 1980 at least and that's over a working lifetime ago."

          Supported by the "Programmersaurus Rex"

          The "Big Beast" of software development.

  6. Pen-y-gors

    How many?

    I'd be curious to know how many Y2K compliance reports they actually received in the last ten years.

    1. Doctor Syntax Silver badge

      Re: How many?

      Probably at least one a year from each reporting body. Basic rule of civil service procedures the world over: once you start something it just continues until you take positive action to stop it. It obvious thing would have been about June 2000 to do a post-implementation review and stop the reporting apart from any remaining issues.

  7. chopper_harris

    Trump is Bill Lumbergh?

    I guess that sums up public sector bullsh*t / bureaucracy

  8. Arthur the cat Silver badge

    A Friday afternoon joke

    Told to me back when Y2K was nigh, by one of the filthiest minded women I've known.

    The K-Y2 problem: when you absolutely have to have four digits in your date.

  9. Herby

    A Y2.1k problem...

    Is also that the year 2100 is NOT a leap year. That is going to make lots of things break. Microsoft had to do lots of things to make/unmake/make the year 1900 a leap year.

    The simple solution to the Y2038 problem is to use unsigned as time_t. Then it is officially not my problem

    Of course, governments are governments and they will ALWAYS screw up things.

    1. bombastic bob Silver badge
      Devil

      Re: A Y2.1k problem...

      "The simple solution to the Y2038 problem is to use unsigned as time_t. "

      should be 64-biits, actually.

      Looks like 32-bit linux still has 32-bit integer as time_t [the libc would have to be updated, most likely]

      64-bit linux has it as a 64-bit integer, however. no problems there.

      but I'm pretty sure that the 'time since epoch' i being stored internally as 64-bits within the kernel. If someone finds differently, it would be interesting to know.

      however it looks like libc itself (on 32-bit machines) needs to be fixed.

      1. Anonymous Coward
        Anonymous Coward

        Re: A Y2.1k problem...

        Iirc 32bit support is being phased out... at least for programs, not sure about the whole distros.

    2. Jeffrey Nonken

      Re: A Y2.1k problem...

      Actually, the fact that 2000 WAS a leap year broke a lot of stuff.

  10. Suricou Raven

    Politics

    "I found some really obscure government rules that no-one follows anyway. See how much I love repealing red tape and freeing American businesses of regulationl #MAGA"

  11. -tim
    Coat

    That reminds me

    We have a file folder full of Y2K report requests that we never quite got around doing or even sending to the circular file. We now keep it around for comedic value. Maybe we should get an intern to answer them.

    1. Hero Protagonist

      Re: That reminds me

      Never too early to learn about useless bureaucracy

  12. Anonymous Coward
    Anonymous Coward

    Man

    I'm still paying off that $91,250 Blockbusters late video rental fine.

  13. bertvl

    Actually, this is a bad time to cancel Y2K compliance, as some more bugs are going to start crawling out of the woodwork in 2018, as the children born in 2000 turn 18 years old and start signing up for services as adults. Banks and financial services in particular could be affected.

    We hit a Y2K bug at work in 2014 as some government-assigned IDs issued in the jurisdiction where I live are given from the age of 14, and they use a 2-digit year (we validate age from the ID).

    1. Diogenes

      This is also happening for some systems that i have to use as a teacher. What is particularly galling is that in my previous life as a developer, i designed those systems and they were y2k compliant when written in 1987! Admittedly the code has changed, but 95%of my database design is still inuse, with extra tables for new functionality

  14. GrapeBunch

    Resolved problems sometimes un-fix themselves

    Food and medicine here in Canada often come with a "best before date", known elsewhere as an Expiration Date or Expiry Date. In the early times, months were often coded in two letters but of course MA could be March or May. JU could be June or July. So to make the code more readable by humans, they used the first and third letters: MR, MY, JN, JL. Problem solved? No, in recent months I've started to see MA again. Nimrods. No offence intended towards people named Nimrod.

    I worked for an organization that offered life memberships. How to code that? In the 1970s, when this problem was initially encountered, it was with the expiry date 1999-12-31. The date arithmetic would always work out (whether in 2-digit or 4-digit year formats), at least for a couple of decades. Of course, if somebody's membership expired on 1989-12-31, and they bought a 10-year extension, you'd fudge it by giving that person an extra day. It was a nominal expiry date. It should never be published verbatim, but sometimes in those days computer processing could be too primitive. The nominal date would slip out, and complaints would trickle in.

    Around 1980, I computerized the membership database. I used two-digit years. I knew that the code would need to be massaged in less than two decades. Had nobody heard of code maintenance? Using two-digit year codes was often drawn in the popular press as lack of foresight, but I am unrepentant still.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like