SoylentNews is people
SoylentNews
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
(Score: 5, Interesting) by Mykl on Friday January 10 2020, @06:00AM (8 children)
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)
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)
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)
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)
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
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
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
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
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.