Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Friday January 10 2020, @05:22AM   Printer-friendly
from the Zombies-from-another-century dept.

Thought the Y2K bug was over and done with? Read the New Scientist article A lazy fix 20 years ago means the Y2K bug is taking down computers now and think again!

Parking meters, cash registers and a professional wrestling video game have fallen foul of a computer glitch related to the Y2K bug.

The Y2020 bug, which has taken many payment and computer systems offline, is a long-lingering side effect of attempts to fix the Y2K, or millennium bug.

Both stem from the way computers store dates. Many older systems express years using two numbers – 98, for instance, for 1998 – in an effort to save memory. The Y2K bug was a fear that computers would treat 00 as 1900, rather than 2000.

Programmers wanting to avoid the Y2K bug had two broad options: entirely rewrite their code, or adopt a quick fix called "windowing", which would treat all dates from 00 to 20, as from the 2000s, rather than the 1900s. An estimated 80 per cent of computers fixed in 1999 used the quicker, cheaper option.

"Windowing, even during Y2K, was the worst of all possible solutions because it kicked the problem down the road," says Dylan Mulvin at the London School of Economics.

I seem to remember that credit card companies instead kicked the can on to 2050.

-- hendrik


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 2) by Snotnose on Friday January 10 2020, @05:38AM (12 children)

    by Snotnose (1623) on Friday January 10 2020, @05:38AM (#941777)

    If I was choosing the windowing option I'd make a big note, memo, or email saying "fix this within 20 years or else".

    Yet here we are. There's really no excuse for this.

    --
    Bad decisions, great stories
    • (Score: -1, Troll) by Anonymous Coward on Friday January 10 2020, @05:43AM

      by Anonymous Coward on Friday January 10 2020, @05:43AM (#941779)

      Every time an issue or bug like Y2K or Y2K.02 creates panic, it's an opportunity for the Jews to profit.

      1) Artificially create panic or turmoil so people sell stocks

      2) Buy those stocks at cheap, deflated prices

      3) Once the panic is over, pump and dump

      4) Profit at the expense of anyone who sold stocks during the panic

      While stocks are a relatively recent innovation, Jews have been following this basic plan for millennia. Y2K and this bug were created intentionally.

    • (Score: 3, Funny) by c0lo on Friday January 10 2020, @08:58AM (1 child)

      by c0lo (156) Subscriber Badge on Friday January 10 2020, @08:58AM (#941817) Journal

      If I was choosing the windowing option I'd make a big note, memo, or email saying "fix this within 20 years or else".

      I reckon they actually did make such a memo. Their only mistake? They didn't date it (grin)

      --
      https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
      • (Score: 3, Touché) by MostCynical on Saturday January 11 2020, @12:00AM

        by MostCynical (2589) on Saturday January 11 2020, @12:00AM (#942085) Journal

        Worse, they did date it, but used a two digit year, so a clean up script deleting everything older than five years wiped it.

        --
        "I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
    • (Score: 2) by sjames on Friday January 10 2020, @10:51AM (3 children)

      by sjames (2882) on Friday January 10 2020, @10:51AM (#941824) Journal

      The developers probably did exactly that. Then the technical debt was studiously ignored for 20 years because management whated whizz-bangs.

      • (Score: 5, Interesting) by Anonymous Coward on Friday January 10 2020, @03:58PM (1 child)

        by Anonymous Coward on Friday January 10 2020, @03:58PM (#941917)

        Here's the scenario that I see constantly that could have happened.

        Developer has tight deadline and has to choose a quick fix to something.
        Developer enters a bug into their bug system describing the right approach, with relevant details, risks, etc.
        Bug is placed into backlog to prioritize at a later time.
        Bug sits, and sits, and sits.
        A new manager/leadership comes in 2-3 years later, and sees a long backlog of bugs in the bug system.
        Manager deletes all bugs older than 6 months because "if it was important someone would fixed it, or someone would have escalated it by now. And if someone cares, they can ask we re-open it".
        No one notices the bugs have been closed, so the original developer's reminder to fix it the right way is lost.

        I can't count the number of times I've seen this done.

      • (Score: 0) by Anonymous Coward on Friday January 10 2020, @11:21PM

        by Anonymous Coward on Friday January 10 2020, @11:21PM (#942076)

        One of my friends used to do that kind of work. He said that when the consulting firm he worked for had a tight deadline in the lead up to Y2K, their design of choice was to move the window to 1940-2039. Their thinking was that the 2038 bug would rear its head before then and require a proper rewrite anyway. For many systems, that took as they could convert the old data in batches or do quick hacks around dates in the future that have to have occurred in the past (e.g. DOD before DOB).

    • (Score: 4, Insightful) by driverless on Friday January 10 2020, @11:38AM (4 children)

      by driverless (4770) on Friday January 10 2020, @11:38AM (#941829)

      Pet peeve:

      in an effort to save memory

      In most cases it had nothing to do with saving memory, it was just convenience, dates are written DD/MM/YY because it's quick and simple (except in the US where they're written M/DD/Y/H/27/MY just because it's the US). I've seen dates recorded in the 1700's and 1800's with two-digit years, and they sure weren't trying to save memory back then.

      • (Score: 0) by Anonymous Coward on Friday January 10 2020, @02:44PM (2 children)

        by Anonymous Coward on Friday January 10 2020, @02:44PM (#941879)

        Consider that the ñ was invented as a way to write two "n"s in one place thus saving paper, I think you might be wrong.

        • (Score: 0) by Anonymous Coward on Friday January 10 2020, @06:07PM (1 child)

          by Anonymous Coward on Friday January 10 2020, @06:07PM (#941975)

          The purpose of shorthand isn't to save paper but to make writing faster. Two digits is easier and faster to write than four.

          • (Score: 2) by bzipitidoo on Friday January 10 2020, @07:48PM

            by bzipitidoo (4388) on Friday January 10 2020, @07:48PM (#942005) Journal

            I wouldn't be too sure of that. There's also making reading faster, by cramming more text on a page. Also happens to save paper.

            I do not know, but I surmise that all the wide and short letters were rotated 90 degrees to make them tall and narrow, so they could get more text on a line. 'A' and 'B' were originally written what we would consider sideways: 𐤀 𓉐

      • (Score: 1, Interesting) by Anonymous Coward on Saturday January 11 2020, @04:24AM

        by Anonymous Coward on Saturday January 11 2020, @04:24AM (#942164)

        Writing two digit years is a common human written convention for noting a date (since generally it is clear from surrounding context which century is meant).

        Two digit years in computer programs was just lazy programmers copying the written convention (and obviously not thinking about the implications of that copying).

  • (Score: 1, Insightful) by Anonymous Coward on Friday January 10 2020, @05:49AM (1 child)

    by Anonymous Coward on Friday January 10 2020, @05:49AM (#941781)

    "Windowing, even during Y2K, was the worst of all possible solutions because it kicked the problem down the road,"

    Worst? It worked well enough for 20 years didn't it? And now is just in time for a retirement savings/income boost...

    See also: https://despair.com/products/consulting?variant=12108114919550 [despair.com]

    • (Score: 0) by Anonymous Coward on Friday January 10 2020, @08:43PM

      by Anonymous Coward on Friday January 10 2020, @08:43PM (#942032)

      Windowing is NOT just 20 years.

      Microsoft has it built in to date routines for 50 years.
      Lansa has it built in to date routines for 70 year.

      Both are external changeable without recompile.

      I did mine in 1980 for 266yr period from 1/1/1971 to 100000 days in the future & 100000 days in the past. 5 digit sign number.

  • (Score: 5, Interesting) by Mykl on Friday January 10 2020, @06:00AM (8 children)

    by Mykl (1112) on Friday January 10 2020, @06:00AM (#941783)

    Just do a global find/replace to change "20" to "40". Revisit again in 20 years.

    More seriously, I was tasked with identifying a solution for a green-screen system that had no real-estate left for a 4-digit year. Our answer was to conduct a lookup against a 100-row database table that mapped a long date to an associated short date year (e.g. "85" = "1985", while "15" = "2015". The system administrator just needs to update that table as needed. We recommended an administrative action on the 2nd of January each year to update 1 row of the table for $YEAR + 20.

    • (Score: 0) by Anonymous Coward on Friday January 10 2020, @06:26AM (5 children)

      by Anonymous Coward on Friday January 10 2020, @06:26AM (#941789)

      hold on. you have no space for a 4-digit year, but you have space for a table of 100 4-digit years?

      • (Score: 0) by Anonymous Coward on Friday January 10 2020, @06:43AM (4 children)

        by Anonymous Coward on Friday January 10 2020, @06:43AM (#941793)

        Probably mean on the display itself there is no room. But if you are using a system and language that can make database lookups, makes me wonder why you don't just format it that way.

        • (Score: 1, Interesting) by Anonymous Coward on Friday January 10 2020, @08:45AM (3 children)

          by Anonymous Coward on Friday January 10 2020, @08:45AM (#941813)

          ok. so "real-estate" refers to actual pixels on display. I understand.
          but why not keep the full year internally, and simply display year modulo 100?
          or is it such a dumb system that they have to fake modulo with a lookup table?

          • (Score: 1, Funny) by Anonymous Coward on Friday January 10 2020, @09:02AM (1 child)

            by Anonymous Coward on Friday January 10 2020, @09:02AM (#941819)

            Once while I was working as a data architect, I had a contract programmer request a table be made that consisted of each valid date for the next twenty years along with what day of the week each day actually was.

            We had a nice chat.

            • (Score: 0) by Anonymous Coward on Saturday January 11 2020, @04:20AM

              by Anonymous Coward on Saturday January 11 2020, @04:20AM (#942162)

              contract programmer

              I'm not surprised. By far too many of those are barely programmers at all.

              Ask them to do anything that is not already a library function in the language being used, and they simply can't do it.

              I saw one 'contract programmer' one time, who had been asked to write code that would copy a file from network disk A to network disk B (the actual ask was more than this, but this was one of the sub-tasks towards accomplishing the real ask). He wasted a bunch of time looking for a Java 'file copy' library instead of just coding up a CS 101 'open both in binary mode', {read block, write block} until eof, close both loop.

          • (Score: 2) by Mykl on Sunday January 19 2020, @03:48AM

            by Mykl (1112) on Sunday January 19 2020, @03:48AM (#945181)

            Correct - it was the screen real-estate (80 x 24) that was the problem.

            The system did store all dates as full years internally, and we could easily convert the full stored date into a 2-digit code for display. The only need for a conversion table was when an operator entered a 2-digit date _into_ the system, which then needed to be converted to a full date.

            To answer another poster, we could have just created $CURRENT_YEAR +20, however there were two problems with this. First, the client wanted to have full control over when the dates were changed. Second, the system often used Financial Year rather than calendar year, so we had another lookup in the table I mentioned to ensure that the right Financial Year was picked (a modulo + 6 months would've been riskier).

    • (Score: 0) by Anonymous Coward on Friday January 10 2020, @06:44AM

      by Anonymous Coward on Friday January 10 2020, @06:44AM (#941794)
      Wow that's ugly. 100 rows that's to be manually changed. Not DailyWTF grade but keep at it and you'll get there.

      If you always want it increased every year, you can just have "threshold = CURRENTYEAR + OFFSET". Where CURRENTYEAR is automatically set at a specific time (e.g. 5am) each day (in case the system is down for a few days/months for some reason) and OFFSET is configurable but can default to 20 if you want. You don't want CURRENTYEAR to change in the middle of a transaction.
    • (Score: 3, Funny) by bmimatt on Friday January 10 2020, @06:59AM

      by bmimatt (5050) on Friday January 10 2020, @06:59AM (#941798)

      In these cases we are probably talking flat files, with "sysadmin" hand+hard coding the year on Jan 1, while drunk. What a tragi-comedy this is, is unbelievable. These 'systems' should be called shitstems.

  • (Score: 1, Touché) by Anonymous Coward on Friday January 10 2020, @02:34PM

    by Anonymous Coward on Friday January 10 2020, @02:34PM (#941876)

    unicode got all those "smiling brown icecream" emoticons, i am sure they can make one (or more) where a single char is "200", "201" and "202" ...?

  • (Score: 2) by Phoenix666 on Friday January 10 2020, @03:45PM (1 child)

    by Phoenix666 (552) on Friday January 10 2020, @03:45PM (#941909) Journal

    I was about to flag the neurons I filled with COBOL to fix Y2K last time for deletion.

    --
    Washington DC delenda est.
    • (Score: 5, Funny) by DannyB on Friday January 10 2020, @04:13PM

      by DannyB (5839) Subscriber Badge on Friday January 10 2020, @04:13PM (#941927) Journal

      There was this COBOL programmer around the time of Y2K.

      He realized that Y2K was going to be a disaster on a cataclysmic scale. So he put himself into hibernation with a timer set to wake him up a couple years after Y2K when everything would be presumably fixed.

      He wakes up and finds out that due to a Y2K bug in his timer, he has been asleep for much longer than he expected. It's way into the future. Bill Gates greets him. People can see virtual screens in mid air, and tap on invisible (to us) keys and make gestures in mid air. Life expectancy has been greatly extended so far that nobody is sure how long people will live. There is now plenty of energy for all and unlimited resources.

      The programmer expresses that he's glad his timer woke him up. Bill Gates says, "oh, your timer didn't wake you up. It was permanently stuck on a Y2K bug. We chose to wake you up."

      "But why?", the programmer asks.

      Bill Gates explains, "Well, it's the year 9997, and the Y10K bug is right around the corner, a lot of critical systems need to be fixed, and it says in your records that you know COBOL."

      --
      Don't put a mindless tool of corporations in the white house; vote ChatGPT for 2024!
  • (Score: 4, Interesting) by DannyB on Friday January 10 2020, @04:07PM

    by DannyB (5839) Subscriber Badge on Friday January 10 2020, @04:07PM (#941922) Journal

    Back in the day (early 1980s), I worked on a number of programs written in the UCSD p-System. At that time, we scoffed at the idea that these programs would be around anywhere near the turn of the millennium.

    The cool thing about the p-System was that our code could run on multiple systems -- and this was in the mid 1980's! Apple III, and IBM PC were the primary ones. Aside: we dabbled with Corvus Concept since our software worked with the semaphore locking mechanism of Corvus hard drives to have concurrent access and modification of database records and b-tree indexes. And this is back when we had to write our own database, there wasn't any multi-user databases for microcomputers -- let alone cross platform. So I was not only an application developer, but a database, and framework developer as well.

    As IBM PC began to dominate, we discovered this software from a Canadian company called the Datalex Bubble. It packaged a p-System program as a DOS executable. Very cool. And we built our own solution to run on Macintosh in "text mode" by creating our own "terminal emulator".

    So this software continues to evolve into the 1990's. Now Y2K is around the corner.

    It turns out that dates in the p-System take up 2 bytes. 7 bits are allocated for the year. So years could be from 0 to 127. But users could only type in 2 digit years. So our single date input routine in our standard library was modified to treat years 00 to 27 as being stored as a "year" of 100 to 127 in that 7 bit range. So even date subtraction (days between 2 dates, etc) and other date arithmetic would work. (eg, date plus/minus number of days to get another date)

    Thankfully by the early 2000s, all of these ancient text mode programs had been fully converted to GUI programs across our entire customer base. But some of them hang on to the text mode versions as long as we would let them. Now everything is going to web based SaaS. We did offer the server as an installable product at the customer's premises on customer's equipment. But only a tiny handful wanted that option so we discontinued it. They all seem to prefer it "in the cloud".

    --
    Don't put a mindless tool of corporations in the white house; vote ChatGPT for 2024!
(1)