Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 13 submissions in the queue.
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: 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).

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2