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/nottscomputer
Computerphile is a sister project to Brady Haran's Numberphile. More at www.bradyharan.com
![[TH]FFWS SEA Spring 2024 Knockout Stage - Day 11](http://i.ytimg.com/vi/Qr0L1ab9dLE/mqdefault.jpg)
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.
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.
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 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.
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.
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.
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. :-)
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.
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.
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 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
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!
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.
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.
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!
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
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).
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.
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.
Always enjoy your videos Steve. Have a happy new year everyone.
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).
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.
Big respect who sorted out and fixed the problem.
Amount of time spent doing it.
Aw, I was hoping for a few stories of what actually had to be updated, and what might have happened if it weren't.
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.
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
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!
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.
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.
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.
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.
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.
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.
Matt Parker"s book Humble Pi also mentions a couple of interesting bugs similar to this.
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.
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.
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...
Dr. Steve missed the most known example: TH-cam hitting the video watch limit back in 2014 - 2,147,483,647 views
"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
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.
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!?
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.
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...
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.
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".
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.
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.
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.
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.
Thanks Steve (and Tom)
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
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 ...
A happy new year and all the best for the year ahead - 1920.
100 years ago
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 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!
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.
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).
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.
I know I was amazed that my program was used for eight years!
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 )
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 =)
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.
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!
Don't apologize, day month year is the proper date format
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.
I got that Todd Howard Bethesda reference
This guy is ridiculously smart. Love the way he explains stuff.
I remember my uncle who programmed for banks started to tackle the problem back in '94.
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.
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?
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
Kidney Machine at hospiral has Y2K bug since 2000. All computer and gadget etc not affected and was installed Y2K.
Why does a kidney machine even need to know the date. All it does is filter blood.
For one thing, it may log its use. It may also use an internal clock to figure out when it needs to run again.
Since it apparently still runs, it must not be anything too important. Still, it makes sense it might have an internal clock.
That killer opening line.
I love that he is using spreadsheet tractor paper as a scratchpad.
I remember RAM costing £100 GBP per MB in the ‘90s. But then a 4MB upgrade to a 1MB base system was significant 😱
Can't wait for Y10K :)
@9:23; Glad to know the only programmer after Dr. Steve Bagley over his solution to a cycles counter is from several million years or something in the future.
At first I thought "well that'd be really crazy for storing historical dates, too" but then I realized that any software made to handle historical data would probably have already dedicated the extra memory to extended date storage, since that's a primary concern of the system.
Lovin computerphille. But could u do more theoretical CS content? You should do a video on mathematical logic and the curry howard correspondance.
Another millennium bug that we ran into is that century years are handled differently than standard leap years.
20 years later, people still celebrate new decade a year early.
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..
The digital odometer on my '96 Volkswagen Jetta flipped over to 0 once it hit 300,000km.
In 1988, I tried to tell our project leaders that these programmes are going to have a problem on Jan 1, 2000. But noooOOOOOooo!
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.
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 🎉
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.
Y2K kept me busy upgrading software packages in the late 90s. I had to attend the data centre on New Years Eve 1999 and spent all night play games on the PC and eating curry. Also got a nice bonus. By the way we had a 2020 bug on Jan 1st this year when a software package failed to process a new license key!! Fixed of course.
Even as late as 1991 when I got my first job as a COBOL programmer memory was at a premium.
We needed to justify every byte of memory we were using.