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: 2) by Snotnose on Friday January 10 2020, @05:38AM (12 children)
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.
It's just a fact of life that people with brains the size of grapes have mouths the size of watermelons. -- Aunty Acid
(Score: -1, Troll) by Anonymous Coward on Friday January 10 2020, @05:43AM
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)
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
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)
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)
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: 2) by hendrikboom on Friday January 10 2020, @05:11PM
Which is why I often mark infelicities with TODO comments in the source code.
(Score: 0) by Anonymous Coward on Friday January 10 2020, @11:21PM
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)
Pet peeve:
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)
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)
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
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
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)
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
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)
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.
(Score: 1, Touché) by Anonymous Coward on Friday January 10 2020, @02:34PM
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)
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
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."
The thing to remember about the saying "you are what you are" is, that saying: is what it is.
(Score: 4, Interesting) by DannyB on Friday January 10 2020, @04:07PM
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".
The thing to remember about the saying "you are what you are" is, that saying: is what it is.