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.
  • (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?

    Starting Score:    0  points
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  

    Total Score:   1  
  • (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).