Це відео не доступне.
Перепрошуємо.
Millennium Bug (20yrs on) - Computerphile
Вставка
- Опубліковано 29 гру 2019
- Was the Y2K bug a complete non-event? Dr Steve Bagley on why it was 'a thing' and how it was worked around.
Advanced Encryption Standard Explained: • AES Explained (Advance...
Multithreading Explained: • Multithreading Code - ...
BCD and Double Dabble Algorithm: • Binary to BCD (Double ...
/ computerphile
/ computer_phile
This video was filmed and edited by Sean Riley.
Computer Science at the University of Nottingham: bit.ly/nottsco...
Computerphile is a sister project to Brady Haran's Numberphile. More at www.bradyharan.com
I remember reading the newspaper in the 90s when it was a 105 year old man receiving a letter from the county about enrolling in primary school next year as the enrollment age was lowered from 7 to 6 that year.
I recall reading about a similar incident. I think it was in Sweden.
@@AnttiBrax not in sweden
@@erikgustafssson8433 Maybe it happened multiple times in multiple places
In the year 1975, I was in a computer science class when the professor was explaining using only two digits code for the year to save memory. I asked what happens when the year 2000 rolls around. His answer was, "we have 25 years until we have to worry about this."
Hahaha I love that answer. Every time I ask my professor an edge case question I get the same answer as that. Ahh...things never change...
Why do you have a ✅?
@@joshix833 verified content creator on youtube... even though he does only have 34 subs lol
@@joshix833 I was one of the first, and before they changed the requirements, that's all, nothing sneaky. It used to mean you are verified who you say you are
I remember learning COBOL in 1976 and was told to use 2 digit years and use 99 as a back stop year. My lecturer also say not to worry that was way in the future.
My job in 1999 consisted of updating several DoD programs to get around the rollover bug. Talk about a hard deadline!
Hopefully you could test the software by advancing the system clock?
@Kenny Phillips Hopefully we're not trying to fix the 2038 problem in 2037
Hopefully we won't still be using 32 bit software in 2038
@@Windfarmer 64 bit programs can also use 32 bit date storage.......
@@oliverhalenius Int in most languages' 64 bit compilers are still 32 bit.
It is interesting how some bits of software were never expected to be long term solutions but are still in use decades later, while other software that is meant to be the last word gets scrapped almost immediately.
chris4072511 If you want a secure niche occupation, look into maintaining and updating COBOL programs.
Needle Noddle-noo What about the TOPS system that controls British railways. It was designed in 1965 to run on an IBM 360 mainframe and either still does 50+ years later it runs in emulation somewhere. It was written in its own TOPSTRAN programming language that no one knows how to maintain, so it isn’t maintained. It remains in use as is unable to be replaced.
@@chrispza I'm looking forward to hearing about some national or global bank in 2037 scrambling to finally update their COBOL code to use 64 bit dates before something crashes.
The airports around Paris use systems, parts of which run on Windows 3.1 and XP; and I remember reading about the control equipment for aircraft in-flight entertainment, ran-until a few years ago-on DOS.
I remember as recently as 2010 coming back from Spain and seeing that the Spanish airport was running check in desks on MS-DOS. In flight entertainment systems as far as I am aware were analogue systems based around Sony Video8 tapes.
The good old days. I remember spending hours updating servers everywhere, checking with vendors for compliance statements etc... then on Jan 2nd we tried to get into the office and couldn't. The electronic card-swipe system had crashed because of... a Y2K bug. That poort little 486 had been locked in a cabinet and most of us did not even know it existed. had good fun forceing the door though,those magnets are freakishly powerful.
So you guided others to a treasure you couldn't possess.
Why did the door lock software running on the 486 need to have access to the date when it could introduce problems like that? I doubt it was capable of recording who opened the door and when if no one knew it existed. I’ve always thought that those magnetic locks could be defeated without even damaging just by forcing the door. I heard about an incident with some lockers in a school. They were brand new in January 2016 with decimal code locks on them and by 29 February they all crashed because they hadn’t been programmed to accommodate leap years. Why does a simple lock mechanism need access to a date? Why can’t it just do it’s job of opening and closing the door regardless of the time?
@@howardmiao5150 Logging when people open the doors is one of the reasons you'd want a digital system. So having the date and time makes sense.
Not accounting for leap years is just irresponsible.
Howard Miao - Audit trails and logging. It is a pretty important component of all access control systems.
@@Aidiakapi So then the date in the log will just be wrong. Not a reason for it to crash. In the case with the lockers, that must actually mean the lockers had internet access because otherwise they'd just keep counting with the skipped leap day.
At the medical research company I worked in, it was all no small thing. About 1995, our computer group formed a ‘tiger team’ to start looking at our code files for date calculations. Most new software was already in 4 digit year form (programmers learned about the bug when they first learned to code). The next 5 years were very busy for the team. I don’t know how many hours they put in but it was substantial. All of there efforts were successful, as we passed the testing. “Planes didn’t fall out of the sky” because of a lot of hard work. I sill write years with 4 digits, just in case.
There will be more glitches around 2100, its not just a millennium thing.
> I sill write years with 4 digits, just in case.
You are safe until 9999 😂
Let's hope no-one uses your system in the year 10k
@@gordonrichardson2972 if people haven't learned their lesson by then, then their systems deserve to crash.
It's especially important this year, even when hand-writing the date, to use four digits. You could sign something as "Tested 07/07/20" only for some lazy tech next year to amend it to "Tested 07/07/2021, etc.
First night school course I took in 1969, the teacher told us of the school admitting program doing year - birth date to make sure the student was over 18. Someone born in 1899 was rejected because they were 69-99 = -30 years old.
First system I supported in business did an invoice detail count and used it to check for vendor break (if not 0).
Problem was it was only 999 (Cobol) and when a new vendor at every 1000 lines, it wasn't treated as a new vendor, and 50,000 dollars of invoices went to the guy that should have made 100 dollars. This system came from the hardware vendor, so it sat dormant on a lot of companies that didn't have the invoice volume.
So I knew what to expect if Y2K bugs weren't fixed.
I'm not into coding or computers but I do enjoy the channel. Anyway what I wanted to say was thanks for this video, I always assumed cause everyone always said that people were worrying over nothing and nothing bad became of it. But now I learned that that only happened because people worked to make sure that nothing bad happened
And it is kind of mind boggling how much work went into it as well. The reason why so much work went into it was people kept finding more and more problems. If that hadn't been the case everyone would have just stopped preventing problems and accepted the few issues once they became apparent.
It's the most frustrating thing about the Y2K bug. The alarmism caused people to fix the problem and so it looks like the alarmists cried wolf.
Oiy oiy Super Hans, it's not all spiders' webs and magic 😉
I knew someone who worked tangentially to a medical system that had to spend many, many millions of dollars making sure the right prescriptions went out on time. Had they not fixed the bug, millions of people would have had their insurance companies reject their medication at the pharmacy, killing who knows how many people. For systems that couldn't just be replaced with a newer version that had to be replaced anyway, it was a massive, expensive effort to fix that damned bug.
absolutely no-one is falling for that
I was in charge of Y2K for AT&T Labs - I remember hiring 30 contractors to fix Y2K issues, mostly in the “free” software we were using at the time. We contributed all the fixes back to the community.
What would exist without Bell Labs ??
@@kerrynball2734 They didn’t invent GUIs.
Open source giveth, and open source taketh away.
I remember some websites for years after 2000 produced dates that looked like 19102
They probably used the Date.getYear() method in JavaScript, which returns the number of years since 1900, and not Date.getFullYear(), which does what you would expect. It boggles my mind how they could design it that way, especially since JS was released in 1995, but that's JavaScript for you I guess.
I'm pretty sure there aren't that many years since 1900.
@@jangxx JavaScript was released in 1995, but the creators probably just used the functions from POSIX (UNIX) or the C standard library, which were designed in the 1970's, and those return the current year minus 1900. And so, alas, questionable design decisions were inherited from that. Programmers need to be careful not to unquestioningly repeat the broken assumptions of yesteryear!
@@Ken.- Date.getYear() returns 102 for 2002. If you print out 19 followed by 102, you get 19102. Yes, you should properly add it, but who bothers? It worked fine in 1995 :)
It works correctly if you write your language's equivalent of printf("%d", 1900 + year); instead of printf("19%d", year); like in the video.
Some devs, *lifts thumbs and points at self*, made a tidy profit in 1998-1999 :)
A lot of the solutions we had to implement were a special kind of genius and often installation/location specific - especially when the source code was *long gone* or uncompilable...
Any specific examples of clever workarounds you guys had to do that you can share?
@@PerMortensen Time travel
I am quite curious as well, if the code is long gone or uncompilable, how did you even inject the fix?
A lot of code was much easier to decompile as the compilers were much simpler and used familiar libraries and system calls you can look out for.
A lot of trial and error and swearing :-D
@@PerMortensen I worked on a system where we had to parse a transaction log from a telephone exchange. This would have been fine but we needed to sort the log to ensure we got all events in the correct order (they weren't necessarily written in the log sequentially but they had a timestamp of when the commands were run) The trick was simple: after sorting the log we just split it into when the year went to zero. In this case we were lucky that this code would be running several hours after midnight. It was similar with billing for calls that started before and ended after midnight.
I was an intern and was responsible for turning off the servers at last day of 1999 and on the next day, just in case. Now I own a cloud computing company and I'm wondering about the 2038 bug...
If you don't mind me asking, I assume that 2038 bug is similar to the y2k, but why 2038? What is special about that year?
@@fernandotorrero779 Unix time is the number of seconds past Jan. 1st 1970. This number is 32 bits, which is 4,294,967,295. 2038 is more than 4,294,967,295 seconds past 1970, so we'll roll over at 2038 and computers will think it's 1970 again. -- EDIT ignore my specific numbers, they're off, but that's the general idea.
@@stevenwhitaker1943 Close. Yes it's 32-bit integer but they used SIGNED - which is worse. 2^31 = 2,147,483,647 seconds past Jan 1, 1970. The rollover will happen on January 19, 2038 at 3:14:08. Wrapping around to December 13, 1901 at 8:45.
@@stevenwhitaker1943 It is only 32 bits on some archs.
Assuming his statement that it crashed after 18 minutes is true, with 64 bits it would crash after around 146,990 years.
That's probably a reasonable amount of continuous uptime
Depends on the scale, TheNasaDude. 😉
Ahahaha.
Let our 6000*great-grandchildren deal with that problem.
In the year 2000, the Perl annual conference intentionally advertised itself as 19100, since the straightforward date() solution returned the year as years-since-1900 ... but lazy people printed that as 19%y rather than 1900 +%y.
Love it
Another bug like Y2K I have seen is in GPS software. I developed a product 10 years back and the first batch no longer works. It seems there is a roll over bug every 19.7 years. April 2019 was when it happened. Later GPS modules did not have this issue.
I am guilty of the issues coming with Unix numbers. Like the 1965 coders I though 28 years from now my units will no longer be in use.
Been there, done that. Some of the GPSs I work with have extended the GPS week number beyond the original 10 bits, but not all do it the same way. A handful, to this day, refuse to count past 1024. :-(
That hit me in April on my GPS logger. I managed to find an update or the software but I lost my tracks, some of I had not yet extracted form the software so they went for good. My bad, I shbould have first secured the data and then fixed the problem. I had no clue on the existence of the problem. It happens every 1024 weeks.
The new GPS standard uses 13 bit numbers to count the weeks rather than 10 bit.
why they didn't use 16 bits I dunno
same with older phones
needforsuv I’ve never seen the code, but a reasonable guess might be that they were using 16 bits to represent the week number AND the day of the week: 3 bits are needed to count 1-7 (or 0-6), leaving 13 bits for the week.
7:44 as it happens, I was involved in a Y2K project involving pensions, and while most of the systems were fixed there was a an older one which we knowingly didn't fix or replace because it was gradually reaching its end of usability anyway, was not deemed as critical (people weren't being paid from it), and we didn't have the original programmers. As expected, it did develop issues after 1/1/2000 to the point where it was almost unusable.
You can tell someone knows nothing about IT when they say "they said the Y2K bug was gonna be a problem and it turned out to be nothing!" I hear this argument said in discussions about the 2038 problem (Unix time rollover).
As our prof always says: „hardware and software are the biggest lies“ in that hardware gets replaced almost on a yearly basis but software is still in use decades after its been written.
And now we write emulators and virtual machines to be able to run the oldest software with the newest hardware... 🙄
In 2010 some debitcards in Germany didn't work anymore, because the year was stored as 1 digit🙈 An update of the chips firmeware was made in the ATM
It shouldn't happen past 2k since memory got bigger though, right? It should prevent that from happening in the first place in cost of more (little) memory usage
@@FireWyvern870 Memory is less of an issue than lack of foresight, though cards are often memory-limits
@@FireWyvern870 In debit card transactions, if you were given a solution between allowing all cards from 1900 to 20XX, or just the cards valid from 200X when needing to check for an expired year. there's presumably a much more smaller target space.
Like, say, if the debit card numbers are assigned by year of issue/expiry when created (I'm guessing it's more complicated than that, but as an example), someone couldn't use a card using the same number as one expired in 2006 in 2009, because the card was fraudulently claimed to be expired in 2016. Or a card that was issued in 2216, which clearly means it's not going to expire anytime soon.
Much easier to just say "Sorry - any card expiring before the year 0 can't be used in 2010."
Or at least, presumably faster - and on top of memory limits, debit cards are transacted a *lot*, so I imagine it stacks up.
still, it's only a bit more processing
I hope the customers of those bank have some cash on their hand. Their cards might all have died. Again. Today. :-)
DD/MM/YYYY, oh the joy to see something so right and just on an English language video.
He probably did another version for US viewers...
Exactly! He also doesn’t think that decade gonna end tomorrow.
You guys dont get the Americsn version of Numberphile? All of our zeros are replaced with ovals.
Sigh: That is not proper date format. That is why it is wrong. We should use YYYY-MM-DD. We don't write 9102 nor 1920 to write this year, 2019. We also have the ISO standard date in UK and USA and all over the planet.
@@AndersJackson ISO 8601 FTW!
Also the national standard in Japan. For all their quirks, that’s one thing they did that makes sense.
I remember in the mid-1990s, working on the first automation system for the NZ DNS registry, and learning Perl at the same time. The script we started with (from the Australian registry) was storing 2-digit year numbers. A (presumably more experienced) colleague immediately said not to worry about it, that there was no way our particular software would still be in use by the end of the century. I disagreed and insisted that years be stored as 4 digits. That was purely out of instinct, which turned out to be correct.
Sorry, not 16 bytes, 2 bytes.
in 1999 I was the one volunteer IT person at a small US National Park. While I didn't have to debug software I was responsible for making sure all software and computers that were older than a given date had been replaced or upgraded. There was a lot of money available to replace stuff. As it turned out, because we worked to update everything across the entire National Park system, the only things that were affected by Y2K were a couple of digital thermostats in one of the large parks.
In 1999 I was given a sealed can of little chocolate IC's, called "Millennium Bugs"
That's all I remember about it!
Dr. Steve missed the most known example: UA-cam hitting the video watch limit back in 2014 - 2,147,483,647 views
I was working for a company that ran a large number of web sites. Of course there was no consistency across the web sites, so dates were in multiple formats. Companies that handled subscription payments did who-knows-what, while at the other extreme, we had to ensure the picture-of-the-day was not a duplicate. Nothing went wrong, but making sure it wouldn't was a pain, and we had a New year's Eve party for all the programmers, so all the experts would be on hand.
A lot of the systems at my organisation started misbehaving 18 months before the millennium. We had two teams: "The Quick Fix Team" ("Get It Working, work around... Move On to the next problem") and the "New System" (Where every system, hardware device and procedure was guaranteed to be 2K Compliant). It was still a very nervous time when the clocks rolled over and it was a few days after the change that we breathed easily again.
In 1998 I did a Y2K audit in my apartment. My VCR failed, but everything else was fine.
On The Day I watched things happen (or not...) on three midnights: midnight in New Zealand (UTC+13), midnight UTC, and local midnight (UTC-5).
Samoa was the last inhabited land to start the year 2000 but in the end of 2011 Samoa shifted to future side of IDL to enhance business works with Australia and New Zealand
Fun aside... one of the contracts my dad worked on back in 1984 was updating the software for a bank to be Y2K compliant. By that point, the extra 2 bytes were coming way down in cost, and some organizations were very on top of it. Some not so much, lol. I, for one, do not fear the Y2K bug, I fear the Y2038 bug. ;)
What's the y2038 bug?
@@Damo2690 He discusses it later in the video - that's when the 32-bit integer rollover will happen for Unix time. Since Unix time is counted as the number of seconds that have elapsed since 12:00 am, January 1, 1970, that means that any system still using a 32-bit integer to track the time will think it's 1970 again. Just about every computing device connected to the Internet uses Unix time these days, but it's more of a joke though -- while that rollover will happen in the middle of 2038, pretty much everybody switched over to a 64-bit integer years ago and it's exceedingly unlikely that anything will be impacted by it at all. We also won't have to worry about the 64-bit integer in our lifetimes, lol - that doesn't roll over until about 10,000 years into the future.
@taragwendolyn The wraparound date for 64-bit systems is 10,000 years into the future? Everywhere else, I’ve heard that the date is twenty times the age of the universe.
I love how the fix isn't "hey lets solve this forever" but "hey let's just make this be a problem several million years from now"
It's impossible to solve it forever
@@circuit10 I wouldn't say impossible, just really not worth it
@@circuit10 I know, infinity causes all sorts of problems.
@@OrcinusDrake It's impossible because eventually the computer wouldn't have enough storage space to store the date. The universe will have ended by then though.
@@circuit10 But by the time that would be a problem you'd have (far) better hardware to handle it
I remember a whole bunch of computer advertisements that tried to play up the Y2K issue "Make sure you buy our computers so you'll know it's Y2K Compliant!" "Bring your computer down to our store for a Y2K test" and so on. There were absolutely some commercial computers that NEEDED to be Y2K compliant, but most home users would have been mildly inconvenienced at worst, and a lot of Y2K related computer adverts didn't go out of their way to mention that part.
Matt Parker's book gives a similar example of F-22 jet fighters flying over the international date line, their control systems used GPS time in the flight systems, and when the army did flights near the IDL, the rollover of -24 hours would crash the control system and shut everything down on the plane, - a scary situation for the pilot!
The IT department I worked in during Y2K did our research & tests and knew what was going to fail. The payroll system (a late 1960s relic) was going to fail and 700+ people wouldn't get paid. Bugs me that people think it was nothing. It's thanks to a lot of hard working people why it wasn't a big deal. Kudos to those unsung heroes.
Let's not forget that even as late as 1995, easily a decade after people were already fixing the bug in their legacy systems, new tools were being shipped with the Millennium bug. JavaScript's date library assumed a 2-digit year with 19 prepended to it. Yes. In 1995. It was Microsoft's JScript in mid-1996 that offered an alternate data library that didn't have the bug. It ended up being the date library in the ECMA Standard 262 standardized version.
In the 1980's we used a coding trick that depended on storing a date in 6 digit field. To convert MMDDYY format to YYMMDD format we'd multiply the MMDDYY date by 10000.01 truncate to right most integer part and you get YYMMDD that can be easily sorted. In that system it was a single instruction. It's the same as mod(int(date x 10000.01), 1000000) . We used it in thousands of places in the code for an early Electronic Health Record (EHR) system (we called it a CPR back then, Computerized Patient Record). This was used to sequence medical records and schedules. We never imagined that the system would still be in use beyond the year 2000. Wrong, Parts of the system still run in some hospitals to this day. I'm glad I wasn't around to fix that one!
I was a software engineer writing code for embedded systems from 1977 to 1985, and the standards I was working to already included the possibility that the code would still be in use after 1999. The same applies to all safety critical systems of that era. The problems that did arise were the result of lazy programming of business software and poor coding standards. The fact that many programmers thought that planes would fall from the sky and life support machines would stop working, is down to people judging software engineers by their own sloppy standards.
I remember running software on all our office machines to see which had BIOSs that would fail and then replacing them and several bits of corporate software before Dec 1999. Happy times.
My fathers company used to repair man machine interfaces for process control including nuclear power plants. Most of the companies in response to the YTK threat simply replaced their legacy main-frame machines. This had the affect of putting him out of business after 30 years.
My first programming job started in 1998. One of my tasks that year (and the next)...the Y2K bug. The Y2K bug wasn't going to explode our offices or cause deaths anywhere, but it had the potential to mess up billing. Yep, it was all about money for us (and our clients). I spent two years on the Y2K bug. It was a back-burner project, but it was two years of debugging. When 1/1/2000 came around, we only had a few issues.
"99" was hardcoded everywhere, partly due to people copying and pasting code instead of re-using code.
20 bloody years ago. Well someone screwed up royal and sped up time!
Or they got bored and decided to speed things up a bit so they can get to the end game faster.
@@beskamir5977 Someone is definitely running exploits, it's corrupted the broader quantum time slicing.
Human's sense of time is relative. Each subsequent year of life is a smaller percentage of one's total life experience so each year feels to pass more quickly.
@@-41337 Yep, plus if you didn't form unique memories during a period of time then looking back on it will seem like it just whooshed past since you can barely remember it. So try to avoid doing the same thing all the time, decreasing neurogenesis in the hippocampus (alcohol, chronic sleep deprivation, chronic stress, etc) and try to do stuff that'll increase your abilities to form new memories (ie exercise, sleep well, fluoxetine, learning, etc).
The other issue around that time was the "odd" February 29th in 2000. First one in a " 00" year since 1600.
patdbean -- How did the computers handle it back in 1600?
@@bokkenka They added a bead to the abacus.
While I appreciate the hardwork that went into solving/preventing Y2kdisasters, I must say it wouldn't have been such hard work and stressful if companies didn't procrastinate all the way until just a few years prior...
This guy is ridiculously smart. Love the way he explains stuff.
Aw, I was hoping for a few stories of what actually had to be updated, and what might have happened if it weren't.
I had a large system with date input having just 2 digits - instead of redesigning all these screens we just decided if the year was greater than 30 assume 19YY, otherwise 20YY - putting the problem off to 2029
That's called a sliding pivot year, and pushes the problem down the road...
Lazy coding that caused the issue in the first place !
Hanniffy Dinn
The system was developed in 1978!
Anthony McCartan so In 1978 nobody believed the year 2000 didn’t exist? Were they all stupid? I don’t think saving one byte was a large memory issue in 1978!
@@hanniffydinn6019 You obviously have no idea what systems and software were like in 1978!?
6:08 I think we are missing a leading zero on the format specifier. %02d Without this there would only be 0 not 00.
I think he is assuming the value going into %d would be 100, not 0. Unless there is some sort of type that wraps around after 99 :S
@@bassbreaker Yes, his output was 19100. But for 1900-1909 it would be wrong without the "02" formatting.
"Sufficiently far into the future" - is where this issue started!
For reference though, a signed 64 bit Unix timestamp will take over 290 million years before it'll be a problem again. Not the kind of timescale I'd worry about.
I think he is talking about the 32 bits one
6:05 That happened to me on some programs.
What happens when you hit a bug that you did not even expect. Last April my GPS logger started to show funny dates. I had found out that every 19 years or so GPS week number rolls over. I ended up losing some tracks I had intended to use for geotagging.
The GPS standard used to use a 10 bit integer to count the weeks, which would roll over every 19.7 years. The newer standard uses a 13-bit integer to count the weeks.
I am 20 years old, and I am still getting my pension.
Which, at 1965 rates, must be a tidy sum! Congrats...
I remember sitting with my grandfather and setting the system date to simulate the transition in Windows 95 to settle his nerves about the whole thing.
Fortunately the Company I worked at decided to hold dates in the format of 2 fields, the first being months since 1850 and the second day of the month. This allowed them to hold dates as binary values in 4 bytes. As an insurance company we needed to allow for people born in the late 1800's.
A lot of people, especially the media, used hyperbole to treat it as a joke (because they didn't understand it), which just made other people use hyperbole to treat it like a joke, and so on. Instead of actually listening to what people who knew what they were talking about.
The two arcade machines at the local pub stopped working and they sold them off rather than hire someone to fix them. It was heartbreaking.
2038 problem: The real Y2K bug.
As he said is not that big of a deal, just recompile the kernel using 128 bit for storing dates. But by that time most releases will be already fixed, unless you are using a literally 20+ year old unpatched distro.
The great thing is that when we wrap back to 1970, Dr Bagley’s shirt will be fashionable again.
AI will solve it
@@eFeXuy 2038 is the end of 32 bit unix time. the end of 64 bit is well past 200 billion years from now, the earth sill be long gone :)
eFeXuy like many companies do.
I, too, was an engineer in the defense industry then an we spent a lot of time cleaning up those issues. I honestly thought there would be more problems that got through than actually did. There are still a lot of other epoch issues in lots of different systems for many different epochs (like 1970 in Unix).
I modified a few programs back then so that if the program needed to compare two dates, it would prefix a 20 to any date less than 20 (making 13 into 2013 for example), and prefix 19 otherwise. That was the “windowing” technique. If those programs are still running, they will malfunction this year.
Today we catched a bug that when you use "YYYY" to represent date in Java, today it will say that is "30-12-2020" instead of "30-12-2019", because the correct representation of year is with "yyyy". Java uses "y" to represent year, and "Y" to represent "day week year"
Tom Scott's last video is all about it.
Oh. I didn't realize this was a recently discovered bug.
@@Nadia1989 Oops, didn't see. I'll see now, thanks!
@@ZipplyZane It's a "recent bug discovered" in our company, that used "YYYY" as year representation =)
that bug me that 2 diget like "99" is 4+4 bits and 8 bits is max 255 (unasignd) you can save them as one byte and you have from 1900 - 2155 if you have 1900 as acont an add the value
( 1999 = 1900+b1100011 )
In 1996, I started seeing stars in place of the year in the main database I had access to at work. Eventually, I started seeing 30 November 1999 for a date way ahead of time, and I couldn't understand why. Then I realized that it's the day before the first day of the month before the first month of 2000, so it was essentially recording the date as 2000-00-00.
Years ago I found in my office a quote for a service that checked if your computers if they were 2000's ready, but it was just checking if the PC's bios supported 4 digit years, and other unrelated thing like antivirus and offimatic suites.
Such a scam, that was a decade before I started working and never asked if they actually bought the "service".
Matt Parker"s book Humble Pi also mentions a couple of interesting bugs similar to this.
I remember a story (probably completely fabricated) than in 1998 there was a car showroom that had just added some new vehicles to their system and one of the things the system did was recommended how much to discount a vehicle that had been sat there for a long time.
Apparently it would do this but adding a number to the date the vehicle was entered into the system and checking if the new date was greater than this value.
This lead to the system thinking cars had been on the showroom floor for over 100 years and was suggesting they basically give them away.
LOL!
Always enjoy your videos Steve. Have a happy new year everyone.
I particularly like this quote on the Wikipedia NTP page (Network Time Protocol, in use since 1985);
"Future versions of NTP may extend the time representation to 128 bits: 64 bits for the second and 64 bits for the fractional-second. The current NTPv4 format has support for Era Number and Era Offset, that when used properly should aid fixing date rollover issues. According to Mills, "the 64 bit value for the fraction is enough to resolve the amount of time it takes a photon to pass an electron at the speed of light. The 64 bit second value is enough to provide unambiguous time representation until the universe goes dim."
Now that's what I call being far-sighted!
Where did the time go. I remember being driven crazy by our y2k project manager who was previously an accountant and not an IT professional. The amount of prove he wanted to prove my code was Y2K compliant was huge way beyond was really needed.
I believe there is a similar-ish problem with all windows computers, where the calandar programmed into the computer is either missing a leap year or has an extra leap year I can’t remember, and so the computer is constantly tracking the date incorrectly, but because so many systems and programs are built around that, they can’t change it they just have to bandaid over it
8:47 et seq - one generation of systems that our company makes requires rebooting at least once every 248 days to avoid the Solaris OS crashing due to a counter overflowing (2^31 centiseconds ~ 248 days). In the next generation of systems I fixed a similar crash, this time in our software, where a counter would roll over after 49 days (2^32 milliseconds). I've also fixed weird behaviour due to using too small a variable to measure time such that the system thought the current time was in the past, etc.
It is possible to implement workarounds for overflow, in a similar vein to TCP/SCTP sequence number comparison where you treat a "negative" difference of up to half the range of the value in magnitude as a positive difference instead. However, with memory so cheap these days it surely makes more sense to just switch to 64-bit variables for all time-related things and forget about it.
Depends what you're programming, of course. Full-blown computers have plenty of space for 64-bit variables. Microcontrollers, on the other hand, often have *very* little RAM. (Even the relatively powerful one used in a typical Arduino only has 2K).
Actually, there had been a big alarm about this written back in the late 1960's in a paper from Berkeley about the year 2000 problem. This was a known issue going at least that far back.
It was not just core memory that was a costly and scare resource, tape and disk storage were also very expensive.
I remember in january that we were ridiculed for having invented and exaggerated a problem. Noting happened! We were fraudsters. So I wrote a letter to a paper giving an apology. We had indeed misunderstood the task at hand. We had worked under the assumption that we should FIX the problems, but it seemed that we really should have caused the end of the world.
Part of the millennium bug that very few people knew about was the software that controlled missile defense systems. Part of the software was a "fail-safe" that would cause missiles to launch if a control code was not received in a certain regular time interval to acknowledge that things were still "O.K."
With the millennium bug, this time stamp would suddenly take a decades-long jump which would trigger the automatic launch sequence, All of these defense codes, not only in the U.S.m but also every other nuclear country, had to be corrected prior to the turning of the century to prevent an "accidental" nuclear launch.
Don't apologize, day month year is the proper date format
No it was not a scam. We started to work on checking for potential Y2K problems at Bell Canada starting in 1997. IIRC, there were zero Y2K problems at companies where people took the Y2K warning seriously.
I got that Todd Howard Bethesda reference
My parents withdrew $25,000 from the bank in fear of Y2K bug. The bank did not appreciate it, as they were bleeding money from people making panic withdrawals.
So, as I understand it, basically the millennium bug was a sort of date-based integer overflow?
"String based number overflow" would be technically accurate as it was caused by representing a number as a fixed length string.
It's not an off-by-one error. You work with computers, you start counting with zero. Tomorrow marks the first day of the new decade 🎉
By 2010 most people had already forgotten the concern about the Y2K bug and have reverted to writing two-digit years. Couple that with a wild assortment of punctuation used to separate days, months and years and crazy permutations on the order in which the values are presented, and you have one big mess. Having tired of the mess years ago, whenever possible I now use ISO 8601 date format in my work, i.e., YYYY-MM-DD.
Of course then there will be the Y10K bug!
Milosz Ostrow To be fair the presentation of dates isn’t so much of an issue, it’s when there’s any date based logic that problems arise. As long as the underlying data structure holds the full date then everything should be ok.
@R Brown - At least we have 7980 years of breathing room on that one.
@@The4Crawler RFC 2550 covers rollover from 9999 to A9999, and fixes all year-stored-as-ASCII-character representation issues (excluding a few known issues).
I remember people claiming if something such as the CMOS/BIOS of a PC was to hit 1/1/00 it would blow up. I had to prove to my family with two computers it wouldn't happen. Made a IBM AT 286 and a Acer 486 force change the Date and nothing happened. the 486 went from a two digit year to four. I guess AMI had the plan for y2k back in the late 80s early 90s.
The millenium bug will happen. It didn't in 2000 thanks to the work that has been done, but some of the choices has been to consider a pivot year. If the year is before the pivot year, a 2-digit date is considered as 20YY, if it's after, then it's 19YY. If such a piece of software is still in use nowadays, we have the Millenium Bug around 2025 ... or 2030 ... or tomorrow :-)
A lot of 'fixes' to Y2K involved a sliding pivot year, which can be updated.
As someone how haven't touched a PC before 2000, all the buzz about the Y2K bug back then really drove my curiosity towards computing.
Yes. I was on call that night back when I worked in IT. Can't believe it was 20 years ago!
I was retrenched on 31 Dec 1999. Not my problem after that...
@@gordonrichardson2972 The actual bug itself wasn't interesting. But I learned about society with its reaction to it.
Another millennium bug that we ran into is that century years are handled differently than standard leap years.
The millennium bug is coming back and is biting again. Some softwares simply kept two digit years and assumed everything up to 20 to be in the 2000's. They're now rolling over back to the 1900's. Splunk, a commercial logging and and security package had a fix sent out just a few weeks ago.
It's still occasionally an issue!
In 2014, working at a major UK finance company, we had a "data error" where some of our customers had negative ages... because at some point someone had done something daft in Excel and some of our oldest pensioners DoB's switched from 1925 to 2025.
people born in 1925 would be 95 by now. Not many live to 95.
Law of large numbers applies. We have millions of customers, so we had enough to get some centennials. Oldest on the books at that point was 104, iirc!
>64 bit integer
>sufficiently far in the future
*calculates how far*
*sees result*
_fuse.exe stopped working_
I remember RAM costing £100 GBP per MB in the ‘90s. But then a 4MB upgrade to a 1MB base system was significant 😱
In May of 2000, when I booted up the computer for the first time that season in the marina where I worked, the year read 19100.
We wrote code like this because *disk space* was expensive, and disk *transfer speed* was slow.
5:18 Did he say "perhaps people didn't know how to program" COBOL?
There is a similar problem with oyster cards in London, not a breaking problem.
The number for a zone uses 4 bits so has a maximum number of zones.
So now tfl runs services to Reading they cannot accept oyster there as they have ran out of zones.
The reason for the limitation with the 4 bits is the earlier rfid cards had a very limiting memory/storage.
However contactless is accepted upto Reading as it is a newer system and doesn't store the journey details on the card.
In the future tfl may make the oyster system work like the contactless one, solving this problem.
Vendors loved Y2K because they could force many customers into upgrading their systems based on this Y2K problem since the older systems weren't "certified" as compliant. So most major enterprise consumers of tech all bought new kit in the latter part of the 1990's leading to a drought in purchases after 2000. This in no small part helped the dotcom bubble to burst in the early 2000's.
Working in the industry at the time, and coming out of University, It was a bit of work to overcome this limitation. It is still ongoing today, as to data capacity and readability. The larger aspect is in commodity pricing of memory and processors and writing code based on the available memory and trade-off between data structures and processing of the data efficiently for that size of memory. Notice this is still a moving target as prices and sizes are still not stabilized. How long is the code going to be in production and when will the hardware make the code obsolete? These factors are not usually considered when developing the code... usually only functionality is the main factor in developing the software due to short term considerations, in other words - make it work for today... worry about tomorrow... tomorrow. BTW, the answer is 42. You just need the right question.
I know I was amazed that my program was used for eight years!
The Y2K bug was got me into micro coding. I had a machine at work that was going to roll over to 1900. So I built a pcb with a micro that was mounted in between the main controller and the printer. When it parsed the date section it replaced the 19xx string with 20xx. I think there was some more checking as it worked with 1999 when I fitted it.
It's especially important this year, even when hand-writing the date, to use four digits. You could sign something as "Tested 07/07/20" only for some lazy tech next year to amend it to "Tested 07/07/2021, etc.
I assume , you're not really into that problem. For example in COBOL it was common to fill a 6-digit date field with 999999 when the data was to be deleted. In times of batch processing this would sort the set to the end of file where deletion could be executed just by truncating.
Back in 1995 in Europe ERP software had to be rewriten because of double currency features for the Euro. In 1993 in Germany there was a major change in post codes after reunion. This was the time to eliminate y2k bugs. But there are many other systems.
And ... the fire department in Berlin did have a big problem with a y2k bug, ending in a down of the emergency control center and notifying fire/emergency trucks where to go by delivery boys at the beginning of y2k.
Other known data overflow was 10 bit time overflow on first generation GPS devices 1024 weeks after starting the GPS service.
Btw: Another bug was the leap year 2000 when not implemented correctly because it was the exception of the exception every 400 years.
I have y2k expert as a skill. Not much requested today for some strange reason.
Change the skill name: buffer overflow specialist.
I still remember a funny error occurring in windows 9x's winfile.exe. After the rollover, the program was unable to display the year part of a timestamp of a file improperly. like 1999-12-31 which was followed by something like ::1-01-01 . And lots of the original DS12887 RTC Chips (usual on 486's and pentiums) caused a problem with time display as well. With 32Bit x86 machines, the next problem will occur after the year 2037. Straightly, this limit will exactly occur on 03:14:08 UTC on 19 January 2038 (everywhere where systems are using 1970-01-01 00:00 as the epoch start). So, switching over to 64Bit is the solution. After that date, the actual date will have two meanings on the old "bitmask-limited" machines. In the NTP protocol time pattern, the rollover occurs already somewhere in 2036. so, this cries after a re-definition for this in time before you can't ask a server anymore what the current time is.
Here’s a similar issue: Boeing have to reboot the computer systems on the new Dreamliner because of a integer storing limitation every 200+ days..
A few years ago we had an extra second added to the time during the summer. I was standing on a train platform and, as I recall, watched the time display say 13:60 (instead of 14:00) for a whole minute, so that proved in my mind that it is a real problem.
Leap-seconds are a whole separate issue, necessitated by the slowing down of the Earth’s rotation. There is no predictable system to how they come in--it has to be determined by actual measurement. One thing we’re sure of, their frequency will inevitably increase over time.
Some people are in favour of getting rid of them. But that leads to its own controversies ...
Yep, in 1970 there was the first bug because at the time they only used 1 digit to count the years,but as it turned out, the computer could only count from 1960 to 1969 as 0 to 9, after that it would reset itself back to 0 ,referinf to 1960,so they decided to add an extra digit to get atound that, it will take 30 years before they faced the same problem ,so once the we were entering the year 2000, we realised that we had to add 2 extra digits to get around that bug,2038 will hopefully be the last millenium bug in mankind history as the 64bit word length as opposed to 32bit word ,will take millions of years before a new millennium bug will happen.
I don't know if he'll cover it later in the video but it's not just the date 4 adding and subtracting but the words significant problems with buffer overflows. There were not adequate memory Provisions made for date spaces and accordingly data and even programming commands to get corrupted as States expanded past their containers