The Y2K Bug Was (And Is) a Real Problem

And that's the Y two K problem. So Y two K stands for the year two thousand and by the way, there's somewhat of a delicious irony at work here, because Y two K is a way for us to shorten the year two thousand and the Y two K problem itself stems from our tendency to shorten stuff for the sake of convenience, even at the expense of long term results.

But I digress. By the late ninety nineties was this growing concern that a great deal of the technology that we rely upon was just going to fail on the stroke of midnight. As New Year's Eve n turned to New Year's Day two thousand, people were worried about everything from toasters to airplanes that we're all gonna just fail spontaneously, and clearly the latter would have a much more catastrophic

result than the former. So today I thought I would really go through what was happening with the HYE two K problem, how various companies tried to solve it, and what actually happened at the turn of the millennium. Uh, that last bit I should probably back off of, since you know two thousand was actually the end of the millennium. Two thousand one would have been the beginning of the millennium. Don't at me. Years don't start at zero, we start

at one. So that means one to one hundred would be the first century, one oh one to two d would be the second. That that's my stance. You might disagree. Let's just agree to disagree and go our separate ways. But I'll also talk about some related issues in tech, including how the Y two k problem resurfaced just last year, because that actually did happen, and there's there's a reason for it, and that reason is kind of tragically funny. Now, the easiest thing to do here is to just summarize

the whole issue in this way. The Y two K problem emerged because of a convergence of several factors. Factor number one is that computer memory is finite. It has a limit. Factor number two is that we often build on top of what came before, meaning the stuff we create twenty years ago becomes the foundation for the stuff that we create today. And factor number three is that sometimes people are lazy. Even if they have the resources to do more than what was capable in the past,

they may just still do the bare minimum. Alright, And because the world did not go up in flames when the calendar switched from two thousand, many people assume that the whole brew haha was over nothing. But it wasn't nothing. Companies had spent billions of dollars, hundreds of billions of dollars to address the issue. They were reconfiguring systems, they were updating code in order to avoid the problem. Some of them really just punted the problem a little bit

into the future. And even today, we still occasionally have instances in which an antiquated system or piece of software generates an incorrect result because of the y u K bug, though that sort of thing never really makes the news these days. After all, a computer producing an error isn't really newsworthy unless something particularly catastrophic results because of that, right,

So let's get to the root of it. In the early days of computer programming for companies and organizations, you know, when programming was moving out of like the research labs and the military institutions. So we're talking about like the nineteen sixties here. Computer memory was a really precious resource. There just wasn't a whole lot to work with, so programmers would try and cut corners wherever possible, trying to

make code in an efficient and effective way. And one decision a lot of coders made in those early days was to take a bit of a shortcut when it came to designated the year. Rather than using a four digit designation for the year, like you know nineteen sixty one, programmers often shorten the year down to the last two digits, and heck, to be fair, we humans, we do this all the time in casual conversation as well as Brian Adams songs or for those of you post two thousand

babies bowling for soup songs. So nineteene seventy five just becomes seventy five. Computers would just assume that the two unincluded digits would be one nine, So the two digit year designation was with the assumption that this year fell somewhere in the century of nineteen hundred to nineteen Well, I shouldn't say century, the one hundred year period between nineteen hundred and nine. No need to go back on that nineteen o one thing, And at the time that

was okay. There were still decades left in the nineteen hundreds. While this computer programming was going on. Computer memory was bound to improve, and surely the future programmers would move to a four digit designation for the year once they had the elbow room to do it. Now, to be clear, this problem was not a new one. In fact, you could argue that this problem actually dates back to before there were computers. So let us take a journey all

the way back to eighteen eighty one. You probably didn't think the Y two K problem dates all the way back beyond a century before the pivotal event. Huh. But eight eight one, or really eighteen eighty was a census year here in the United States, and the US holds a census every ten years. Now, the one in eighteen eighty presented a particular challenge that was evident by eighty one.

So that was that it was going to take a long time to tabulate all the results of that census in fact, Ultimately, it took eight years to tabulate the results of the eighteen eighties census, and this is something that is to happen every ten years, right. And meanwhile, in the United States, population was growing, and it was pretty much a guarantee that the next census was going to take even longer to tabulate unless there was some

sort of major change. And then along came a fellow by the name of Herman hollerith and engineer with a goal to create a machine capable of tallying census results automatically. He was building upon Joseph Maria Jacquard's invention the punch card. Now, Jacquard used punch cards to guide looms as in weaving machines. These these punch cards automated the weaving of certain patterns, so that these intricate patterns that would normally take a very long time to do by hand, could be done

very quickly through the use of these punch cards. Holler has saw this as a way to designate results on a census response. You would have a clerk who would take a response. They would punch some holes into a punch card that would represent those responses, and then feed those two tallying machines that could tabulate the results quickly. So Hollow designed cards that measured seven inches by three inches,

capable of holding just eighty characters total. Now, if you only have eighty characters to work with, every character is precious, So using four of those eighty characters to designate a year would be pure luxury. And so you decide you're gonna cut a corner. You're just going to use the

last two digits of the year instead of the whole thing. Um, if anyone's used Twitter back when it was at a hundred forty characters, you know, like once you started getting close to those hundred forty characters, he had to rethink your message as and how can I how can I make this more concise so that I can get across my meaning? Well, the same sort of thing here. Now, that was for nineteenth century punch cards, which, by the way,

that actually did work. The nine senses took two years to tabulate compared to the eight years of the eighty cents is but that need to conserve precious memory space persisted well into the twentieth century. The prevailing thought was that computer memory would improve over time and would eliminate the need to be so frugal with the programming code. But then people didn't really bank on something called Worth's law.

That's w I R t H. Now in the tech world, there are a few observations that we've collectively decided to call laws. Arguably the most famous one is Moore's law. That's based on an observation made by Gordon Moore, and his observation centered more on the trend of the doubling of the number of transistors on integrated circuit every two years. Actually gets a little more persinkty than that it brings in market pressures and finance and things. But that's a

decent summary. But these days we typically say that Moore's law is a trend in which computers double in processing power and or speed every two years, so that the computer you buy two years from today will be twice as powerful as the one you are currently using. Assuming the one you're currently using as a new computer. Well,

Worth's law is a little bit different. Nicholas Worth wrote in an article in n It was an article titled a Plea for Lean Software that software was placing greater demands on hardware at a rate that was even faster than Moore's law. So, in other words, software was requiring more processing power than computers could easily provide. And that's even taking into account the incredible growth rate of Moore's law.

Programmers were not being efficient and companies were eager to throw in all the possible bells and whistles and programs to attract customers. And when you're trying to build in the capability for your word processor to also play video files, for some reason, you might not have the room to also use four digits to mark the year. You cut

corners where you can so. Ironically, while computer memory would improve and in theory allow for a change from the two digit year format to a four digit year format, a lot of programmers just didn't take that route. Whether it was because they had fallen into a habit and they just used two digits because this is how we've always done it, or because they literally wanted to save that space for something else, just comes down to a

case by case basis. Also, hey, quick side note, the argument we do it this way because we've always done it this way is a dumb argument. Now it could be that the old way is the best way that would be totally valid. If it is in fact the best way, sure keep doing it. You're not doing it because that's the way you've always done it, but because that's the best way to do it. But to only do things one way, because that quote is how it's always been done, en quote, is more often than not

an impediment to progress. Anyway, let me get back to the story now. Part of the story is also about standards and why we have them and why it's so darn frustrating when we refuse to actually use um when it comes to expressing dates and time. There is an international standard we could follow, and it goes like this, four digits for the year, then two digits for the month, then two digits for the day, than two digits for the hour, two digits for the minutes, two digits for

the seconds. And if you followed that then there would never be any confusion. Uh. This provides a precise way to document the specific time, and if we had relied on such a standard, then the Y two K problem wouldn't have been a problem at all. Of course, that would have required us to have the computer memory available to use that standard every time. We needed to have a year in the code, but it would actually work.

And uh, you know, sometimes we just don't incorporate standards because incorporating standards requires effort, and you know, sometimes it's just not feeling it that day. You know, you get up and you're like, you know, I I just don't feel like living up to standards. I certainly can identify with that on a personal level. Well as early as the nineteen eighties, some programmers began to wonder about issues

that might come up closer to the New millennium. In fact, there were some industries that were already dealing with this, but we'll get into that a bit later. This was more about people actually using publications to talk about this issue. So if a computer is looking at dates as two digit numbers, what happens when goes to zero zero? Let me tell you a quick story about a pinball machine that used to play back when I was in college. I promise this relates. And also I just love pinball

and it's one of my favorite stories. I went to the University of Georgia and at you g A's student center, we had a game room that included a row of pinball machines and they were also about two dozen and arcade games, and the pinball machines included some true classics like Adam's Family, which is to date my favorite pinball machine of all time. Twilight Zone another great, very difficult

pinball machine. But once in a while we would also have someone rotate in a new or sometimes a very old pinball machine, and I suppose they must have belonged to some you know, alumnus is private collection or something. Anyway, at one point, for some reason, we got a nineteen seventy nine Star Trek pinball machine from Bally and just so y'all know, I was in college in the nineties, so this was a vintage pinball machine even back then.

The playing field on this machine had this one little button in the floor of the playing field up at the top left part, and it was designed so that when the pinball would roll over it, it would activate the button. And this button was in charge of activating an extra ball after it has hit a certain number

of times. However, this particular machine had a button that would stick a little bit, so it didn't take very much effort to get that extra ball, and I, being the enterprising sort pun intended because of Star Trek, I decided one day that. You know, I didn't have any classes that day. I was going to use this knowledge to my advantage, and my goal was at the beginning of each play just just focus on getting the ball up in that upper left part of the playfield and

to activate the extra ball. That was goal number one. Once I did that, from that point forward, I could just play the game. I could do whatever I wanted because I had an extra ball already, and even if the ball drained, I wouldn't lose a life because that was the extra ball. And as soon as I started playing the extra ball, I would do it all over again. And this meant that as long as I could get it up into that upper left part of the game, I could effectively play this game forever or until I

was exhausted. Well, the score of this particular machine could only accommodate up to a certain number of digits, and I can't remember what it was. Let's say it was a million or just under a million. So I decided I wanted to see what would happen if I exceeded that number. I had the methodology there, and sure enough, when I got to that point, you know whatever, it

was like nine thousand, nine nine or whatever. I saw that the next point, the next thing that I hit that generated points sent me back over to the zero starting point, and the score keeping started over. So satisfied that I had turned over the machine, I had rolled over the score, I quickly finished out the game, and I wanted to see if it would let me set a high score, or if it would, you know, choose my score as the high score. It did not. It

reverted back to the previous high score that was technically lower. Um. So there was a rollover problem. In other words, like once it hit zero, the computer interpreted that to mean that we were back at ground zero. Well, in the early eighties, a few programmers were starting to worry that a lot of systems in software had a similar rollover problem and it was going to all come to a

head in two thousand. With the two digit designation for years, it could mean that computer systems would think the year was starting back over at zero and work up to a maximum before rolling over again. And this could potentially

be a big problem. So, for example, let's say you were a go getter in and you got yourself one of them fancy credit cards, and your credit cards expiration date is in let's say two thousand two, and then you go out and you take your fancy credit card to buy you and someone special, you know, a really nice meal, and you've got, you know, plenty of credit on your card. Everything should be fine. Only when the fancy restaurant runs your credit card, the underlying retail system

detects and error. The system is attempting to verify that your card is valid, so it checks the expiration date, but it's essentially saying, you know, is today's date before or after the expiration date on this card. If today's date is before the expiration date, everything's fine. If it's after, that's a problem. And if the system was using a two digit year designation, it would say, oh, zero two is less than That means this card expired like ninety

seven years ago, and the transaction would get declined. This really happened a lot. Now that's just a sample scenario of something that could happen, the sort of you know, tiny thing that would be inconvenient on an individual basis. But it was just the tip of the iceberg for possible problems. I'll talk about it more when we come back after this break. I mentioned a small scale problem the one that's you know, huge when you apply it

to the entire population. But how about something that's even bigger than that, And let's stick with the financial world and talk about banks. So let's say it's nineteen eighty five when you establish a savings account and you put some money in the account and it begins to earn interest at a certain percentage per year. And the way the bank system determines this is by taking the current year let's say, in this scenario, the current years, and then you subtract from that the year in which you

established your account. So in this example, it would be nine eighty five. That gives us ten that's ten years of earning interest, which then can be calculated and then you know how much interest you've earned on your account, which is pretty simple. But let's say instead, now it's the year two thousand, and you're still using these two digit year designations, and now the bank system is trying

to subtract from zero zero. Now, remember the system is assuming that both of these are happening in the century or the one years between ninet So now the figure it comes up with is negative eight five, and that means that you've earned negative interest which gets pulled from

your account, it overdraws your account. So the real concern was that the Y two K bug was going to lead to numerous computer systems, particularly in the financial world, but not exclusively there, and it was going to cause them to miscalculate things like this, and as a result, you would have widespread system failures. Accounts could get wiped out, insurance policies could get canceled, mortgages could be flagged for foreclosure,

and so on. It would be catastrophic and a huge headache to clean up, and all because we had migrated to computer systems that we're using a two digit format for the year. A few people became aware of this pretty early on, but it took a surprisingly long time for the concern to kind of filter out beyond a small collective. The problem extended well beyond the financial industry.

Anything that was dependent upon a year, even something as simple as sorting a group of files chronologically, started to fall apart. If the computer systems interpreted two thousand as really being nineteen hundred, it could affect navigation systems, communication systems, and all sorts of other industries. Now, from what I can tell, people began to see this as an issue UH and started talking about it beyond internal groups around

the early nineteen eighties, but didn't get much attention. Back then. Some companies like IBM were probably more aware of it. I mean, the company certainly claimed as much, but they kept those discussions for the most part internal, so the outside world wasn't really aware of it. In nineteen eight six, Bruce Olmes wrote an article in the IBM Systems Journal,

Volume twenty five, issue two. It has the title computer processing of Dates outside the twentieth century, and in this article, Olms points out that there's a need for a different approach than this two digit year designation. Omas's solution was to use the Lilian date format, which was his own proposal. This format actually takes the date of the formation of the Gregorian calendar, which was October four two, and thus

designates October two as date one. So the date of the creation of the Gregorian calendar is zero, The next day would be one, the day after that would be two, and so the format goes up one per each day after that date. That would make today's date one hundred sixty thousand, two hundred sixty two today, by the way, being July one, in case you're listening from the future.

Olms also suggested an approach that would use windows of time to try get around the two digit problem, generally speaking for modern systems that weren't dealing with dates and antiquity. He was suggesting that for any years designated as fifty or lower, we assume that those are for the year two thousand, and for any years fifty one or higher, we assume that those are for the year nineteen hundreds.

So with a little coding, the computer system interprets any two digit year number above fifty one to belong in the nineteen hundreds. Any two digit year belonging below fifty belongs in two thousand's. So if the year was listed as seventy seven, then it would mean it's nineteen seventy seven, But if it were listed as thirty three, it would be two thousand thirty three. So he was proposing this as a stop gap solution because it only lasts as long as whatever you're dividing year is, and we'll get

back to that. And this would end up being a pivotal part of many companies Y two K strategies, which, as we'll see, as part of a problem. Ohms also pointed out how simple the problem was in concept, but how complicated it was in practice. Conceptually, the only thing anyone really has to do is go in and change a tiny bit of code and a file. So on an individual file basis, it was trivial. It was incredibly simple. You could do it in a in just a few minutes.

But of course reality is way more complicated, because in reality we have suites of software that all connect to one another, and a change in one of those has consequences for everything else that connects back to it. The interconnectedness of software requires that for these systems, all of these changes to the way that we designate years really needs to happen simultaneously across all software, or else you're

gonna have issues with compatibility. Now, at this point, you're not talking about just go into a bunch of individual files, even like millions of them, and changing a couple of numbers. You're talking about trying to keep an entire software ecosystem stable while you do it, and so you don't interrupt the daily operations, and you also, you know, fix the

underlying issue. That's a non trivial problem. So Ohams writes, this piece for IBM and lays out the challenge and the two digit year format is likely to cause at least some problems as the year rolls over from ninety nine to zero zero. And the scale of the problem for large systems is daunting. It will require a lot of time and effort to address with a careful approach

so as not to disrupt normal operations. And this is in n when he writes this, so you would think, oh, well, that gives you plenty of time to fix things, right, I mean, you've got fourteen years. And it means that people working on the next generation of software products and systems can just avoid the problems of the past, right and just use a four digit year from that point forward. Well,

obviously that didn't happen quite like that. Olams's article and IBMS publication of that article acknowledged that there was an underlying problem in software and computer systems, but the article didn't really go so far as to define the scale of the problem nor the amount of work and money it would require to address the problem. But it certainly established that, y'all, we got a problem. That problem was one with a specific countdown every moment that passed would

bring us closer to January one, two thousand. It was, as many people would describe later, a technical time bomb. Now, from what I can tell, the first person to actually describe the rollover problem as a time bomb was Chris Anderson, who published a half page advertisement in the South African journal Computing back in June of six. And the top of the ad read the time bomb in your IBM mainframe system. And I'll just read you a small part of the copy for that ad quote the date time bomb.

The cause is that no IBM mainframe operating system software or compiler properly caters for a date subsequent to December thirty one. The hardware can cope, but the main system software has a bug. Vmsp vs, e v S e S, p m vs all have the same glitch. This is also true for the compiler's cobal assembler at al end quote.

So Anderson's message continued and issued warnings against investing in companies that rely on outdated systems and making certain that you know your affairs are all in order before two thousand, that your money's in a safe place, that kind of thing, And he paints a pretty bleak worst case an areo in this ad, which you know you could go back and argue and say all of this is is true.

If nothing were to be done like this could have been a pretty catastrophic event at least one that would have been incredibly disruptive for more than a month at least. And he ends his ad with a reveal that he's setting up a group called Deadline two thousand to investigate

and and and coordinate implementation of immediate solutions to this problem. Now, IBM responded to this, and in that response, a company rep argued that it had already anticipated this problem and in fact had taken steps to mitigate it, which changes to hardware architecture and updated software that uses four digits

to designate the year, thus sidestepping the two digit problem. Further, the company said that there are some legacy systems that cannot be upgraded and updated to this this format, but these are limited and work around could follow. And essentially IBM was saying, this is not the big deal that Anderson says it is, and we think he's just trying

to drive up business for his consulting company. Now, IBM was a really big advertiser with this particular magazine, and perhaps coincidentally, the magazine failed to carry any other deadline two thousand notices moving forward. And by perhaps coincidentally, I

mean almost certainly not coincidentally. IBM's response did acknowledge that some legacy systems like disc directories and tape labels wrote alied on the two digit year designation, and that these could conceivably cause problems for people down the line if they never address that problem. I bet you can't guess what happened next, you know what. I'll tell you what happened next in just a moment. But first, let's take

another quick break, all right. I mentioned before the break that a big part of this had to do with tape files, and we're talking about magnetic tape here, the physical medium of storage that we used way back in the day to store information. And some of you might have even had experiences with magnetic tape, whether I mean it could have been cassette tapes. Those are magnetic tape as well. Those are used for for audio, but uh,

some old computers used cassette tapes. Personally, I've had experience with magnetic tape because at one point I was working with a consulting firm where part of my job involved making sure that the company's files went to tape back

up at the end of each night. So the idea was any file that had been changed during that day needed to go into a backup, and I regularly would have to switch out reels of tape and store the older ones away just in case someone needed a version of a proposal from you know, I don't know, five years a go or something, which, to be fair, did

occasionally happen. Now. As part of making tape files, administrators would assigned to each a file, each file and expiry date, so essentially beyond that date, the file would be seen as being invalid, something that a system could overwrite without an issue because the data in that file is no longer relevant and it goes into what was essentially called a scratch directory, meaning it's it's ready to be overwritten.

But this meant that if you were to try and insert one of these scratch tapes into a system, rather than pulling data off of that tape, the system would just overwrite the data on the tape. So anything that was on the tape, even if it was valuable and relevant, the system would erase because it was beyond that expiry date.

That was a real issue was that, you know, with this two digit format, once you go to zero zero, there was a worry that all of this stuff that was being stored on magnetic tape would just be marked to be erased the next time it was put in use. So the time bomb in this case would be the tape files that would definitely expire by the beginning of two thousand due to that two digit date designation, but IBM wasn't too concerned about this at the time because

there were fourteen years left to go. Complicating matters is that these discussions were happening in a pre Worldwide Web environment, which meant that the forums for these discussions were typically computer magazines, and those, by their very nature have a

fairly niche and limited audience. That meant that the folks having these discussions made up a very tiny sliver of the population, and usually it didn't include people who had decision making authority at higher levels within various organizations including

companies and governments. So the folks who really needed to know about this, you know, the executives who are in charge to big institutions like financial companies or airlines or what have you largely remained ignorant of the impending issue until it became undeniable and you know, a critical, acute problem. So then we get to the early nineteen nineties and

the birth of the Worldwide Web. That invention would make it possible for, you know, to to issue communications on a much more broad scale and allow individuals to spread the word about things much more effectively. And now stuff that might have been buried in a few inches of column space in a magazine could get the same spotlight

as major news. At least in theory, people still needed to be able to find that respective web page and then read it and all that kind of stuff, but the potential to spread information quickly became a really big deal. In ninete, Peter di Yeager wrote a couple of articles about the rollover problem. The first was in a Canadian

computer magazine with a relatively small circulation. That article received a fairly derisive response from the Globe and Mail, a national newspaper in Canada that really downplayed the scope and impact of the problem. The second article, published in Computer World, had the sensational title Doomsday two thousand, a title that Dieger says he did not pitch, but was rather assigned by an editor to that piece, and that ended up

getting a little bit more attention. But even then, even people that Dieger was associating with, who were in the I T world, even they didn't seem terribly concerned at that point. Now, while much of the focus on the Y two K problem really centered on the years n you know, when it was imminent, that's when organizations and companies were feverishly trying to fix their back end systems

in software to avoid catastrophe. There were earlier cases of groups kind of coming to grips with it, just they were doing so quietly on an individual basis, which wasn't too helpful for everybody else. For example, I mentioned mortgages earlier.

A common mortgage length is a thirty year mortgage, which meant that back in the nineteen seventies, banks and credit unions were starting to put together mortgages that would terminate in the early two thousands, and these financial institutions discovered that the software they were using to determine things like mortgage payments and such, we're having problems because of the

rollover issue. So they were already seeing the effects of the Y two K problem back in the nineteen seventies because they were projecting out beyond the year two thousand, and that's where they were seeing that their software was was sputtering. By the nineteen nineties, as I mentioned, we started seeing those those credit card examples that I gave

you earlier. People would get a new credit card in the nineties that would have an expiration in the early two thousands, and then discovered that the card processing systems at various retail establishments were generating a card expired error error code even though the actual expiration date was in the future, but to the computers that look like it

was in the distant past. So in these cases, the financial institutions like the mortgage companies on one hand, and then the retail companies on the other hand, all created problem fixes to kind of work around these these problems. But these were isolated incidents of companies and organizations taking the steps necessary to fix or at least sidestep this problem. In the short term, the world at large was still under prepared, which is one of the big issues with

the Y two K problem. It wasn't just that the problem was serious, it was that as people were encountering it, they were readily sharing that with other companies and other organizations, which meant that everyone was having to go through it kind of individually, and it was not the most efficient way to tackle a problem. So there was the sort

of hatch work awareness going on. Companies that had any sort of programs that would project results into the future were likely to run up against the Y two K problem at some point. If the company had either a product or some internal system that made projections, and if that system relied in whole or in part on a two digit representation of the year, there was a good chance that someone noticed something hinky was going on, that programs were not behaving the way they were supposed to.

But it wasn't until nine in the United States when Congress passed the Year two thousand Information and Readiness Disclosure Act and President Clinton signed it into law. The law's purpose was to encourage companies to share their Y two K strategies and in return receive limited liability coverage. The hope was that companies that had found successful workarounds could share those methods with others and speed up the process

of getting everyone on the right track. Essentially, to address this issue of every on kind of going it alone, and they're not being established best practices and workarounds. This also included state and federal government offices. These were lagging way behind the private sector. There was a survey done in ninety eight that showed that the government in the United States was far behind the private sector world, you know, private companies and publicly traded companies. So out of this

grew a new industry. You had consultants who would come on board to try and bring an organization into Y two K compliance, which essentially meant just addressing any gaps that would cause the sort of mis interpretation of the year on the part of computer systems. The big stop gap measure, as I mentioned, was windowing, that is, creating a way for a computer system to interpret two digits

as being four digits. And again I mentioned it earlier in this episode, and it works well enough for any processes that you know originate in the twentieth century, But if you go back further you run into problems as the whole thing repeats itself again. But since computers and software weren't really a thing back before nineteen six, generally it was considered a non issue and an effective stop gap. Making these changes proved to be time consuming and expensive.

The world at large spent hundreds of billions of dollars to update code and get things on track for the change to two thousand. In that process, the media reported on the issue in a way that one could be forgiven to describe as hyperbolic. Now, as I've mentioned in this episode, there was a very real problem, like a host of very real problems that could arise as a result of the rollover, and we, in fact we did. We saw this happening with mortgages and credit cards, like

there was definitive proof that this is an issue. The problems were not imaginary, and in many cases they were not trivial. I've seen some blog posts that have been written over the last few years that kind of ridicule how people were preparing for Y two K, and it trivializes the scope and the reach of the problem, And I think that's about as irresponsible as over exaggerating the

effects of the problem. But anyway, some of the cynical response is understandable because media outlets were talking about how to stockpile necessities like food and water and toiletries and cash just in case the financial systems and payment systems failed, and as I mentioned before, we had seen them fail in the past. So the idea was that people should have a cushion to get them through the worst of

it and wait for solutions to arise. But some media outlets took this to an extreme and it began to sound a bit like stockpiling a bunker for protection for like nuclear fallout or something, and that the very fabric of society would break down and we'd all live in the walking debt. There were fears of elevators stopping between floors and just not moving again, or climate control systems

failing entirely. There were fears that airplanes would fall from the sky, and most of these fears were well beyond reality, but they circulated and they grew. This was the other edge of having access to the web. We're coming up on the end of this story, but before I get to that, let's take one last break. You know, by the late nineties, being online was fairly common. You know,

the World Wide Web was the thing. We had not yet had the dot com crash, So the dot com world was starting to really take off and information could spread very quickly, and a lot of the information was about y two K. I still remember New Year's Eve. My spouse and I went to a club with some friends. It was a ridiculous end of the year slash potential end of the world celebration. Uh. They played Prince's nineteen

nine way too many times. In fact, I would argue that although that song is amazing and I love it, it makes no sense to play it during because you're supposed to party like it's nine. Anyway, we counted down the year, I think three times because no one actually had access to an accurate time countdown. That seems pretty appropriate for y two K. And in the end, once

everything was over, it was peaceful. Nothing catastrophic happened, and the next day we went home, and over the course of the following month we saw an outpouring of frustration and exasperation and ridicule. Rather than a sense of relief that, you know, the various computer programmers out there had spent countless hours creating stop gap solutions to get us through the transition, we saw people get upset about it, and the prevailing sense was that it was much ado about nothing.

That those billions of dollar or is that we spent were spent on a non problem, and that seems pretty weird to me. I mean, the reason there weren't that many problems here in the United States is precisely because that sort of money had been spent on the solutions. The solutions prevented the problems from happening. That was the

whole point. So I'm gonna use a dom analogy. Let's say I got a big, old farm and I happened to see reports that there's this unusual migration of deer moving across the region, and that within a couple of weeks they're gonna be where I am, and those deer could spell doom for my harvest. So I decided, I'm going to spend a large amount of money, and I'm gonna get a bunch of construction workers out there, and we're gonna put a deer proof wall around my farm.

And so I spend all this money, we get the wall up, and then the day comes when the migration is supposed to be in my area, and I go outside and I look at my farm inside these walls, and there are no deer in the farm. I'm not gonna say, man, I wasted that money. I'm gonna say, hey, the wall worked well. Our y two K wall worked mostly. There were some scattered issues with systems that had not yet become Y two K compliant, but they were the exception rather than the rule, at least here in the

United States. In other parts of the world there were more, you know, prevalent issues. For example, there were places in the UK that had trouble processing card transactions for the very reasons that I mentioned earlier in this podcast. Not only that, but we actually saw another outbreak of Y two K problems just last year in twenty This comes back to win doing so addressing Y two K problems,

you you broadly had two major solutions. You could go in and actually reprogrammed stuff, but that was incredibly time consuming and expensive, and for certain legacy systems it was not practical because you still had those memory limitations in place for some of those legacy systems and you literally

couldn't make those changes. Windowing was seen as a stop gap, the idea of being that, well, we're going to have to migrate stuff off of those legacy systems onto more modern systems that can have a four digit year, but in the meantime, let's use windowing. So again, windowing is about picking a two digit year and saying anything above this number should fall into the nineteen hundreds. Anything below

this number is in the two thousand's. So again, if you pick fifty, as I mentioned earlier, sixty six would mean oh, well that's above fifty, so it's nineteen sixty six. But twenty two would be interpreted as, oh, that's below fifty, that means two thousand twenty two. That works for a while, and a lot of programmers who put in a windowing stop gap happened to choose twin t as the dividing line, perhaps because this put nineteen seventy in a prominent spot

near the middle. Nineteen seventy also relates to a similar issue called UNIX time, which I will talk about at the very end of this episode. So when it was two thousand to two thousand nineteen, everything was fine because that windowing stop gap meant that computers were interpreting the year's zero zero to nineteen as being two thousand to

two thousand nineteen. But then we hit twenty twenty, and now the computers were saying, oh, we're back in nineteen twenty now, because that was the number that was chosen by these programmers and the windowing stop gap and systems began to experience problems. This, by the way, really illustrates two big things. One is that windowing was really just man as a temporary patch. It was not a long

term solution. The second is that we didn't learn a ding dang darn thing from the Y two K experience, because it's just the same gosh darn problem as why two K. All we did was punted down twenty years and then didn't do anything to prep prep for that, and so we had the problems again. Also, here's here's a fun bit. One of the pieces of software that was affected by this, fittingly enough, was w W E two K twenty, a wrestling video game, which had more

than its share of problems. In fact, I could probably do a full episode about the incredible train wreck that was w W E two K twenty, but I will leave it here anyway, The company that made it, too K eventually issued a patch that fixed things for as far as that goes. Anyway, There are other problems, but

again we'll leave that for a future episode. Now, I did mention just now that Unix time relates to nineteen seventy, so the Unix time stamp uses a thirty two bit integer, and it traces the origin of time to January one, nineteen seventy at zero hours, zero minutes, and zero seconds.

That is when time began according to Unix. But because it's using a thirty two bit integer to mark the passage of time, and because it's marketing it all the way down to the second, that means there's a limit to how far this process of timekeeping can actually go. And we'll hit that limit on January nine, two thousand thirty eight, at oh three hours, fourteen minutes, oh seven seconds.

At that point, we will have run out of space in that thirty two bit integer designation for time, and then all future time stamps will appear as if they are a negative number because of integer overflow, which will

put the time back to nineteen o one. And you know, just in case you thought travel to the past was impossible, according to computers, it's only not possible at least for timekeeping purposes, and everything that is using a Unix based system will be treating the year as if it's nineteen o one at that point forward. So for Unix based systems,

that means that we have an ongoing issue. There have been some proposed solutions, but they tend to be on a case by case basis, not too different from the early days of the Y two K problem and UH, if recent past is anything to go by, we can expect to see some stop gap solutions thrown in there that don't really fix anything, but they do push the

problem further into the future because we're really good at that. UM. It's unfortunate because with a little work, well not a little work, with a lot of work, we can avoid the issue and not have to do triage every few decades to correct the issue we have of not creating a permanent solution UH and replacing a stop gap and instead our habit is to go with the stop gap approach because it's faster to implement, it's cheaper to implement, and we just collectively think that's a future me problem.

And I'm as guilty of doing this kind of thing as anybody else's. In fact, I would argue I'm even more guilty of it. So I'm casting a lot of shade here, But someone that's got to hit on me. Even though I'm not a programmer, I've definitely fallen into that same sort of trap. But I hope this gives you a better appreciation of what the Y two K problem was and is, and why it's such a big

deal and why like people were flipping out about it. Uh, And yeah, it can be kind of funny to see the extent to which some people were flipping out about it and worried that it was going to just bring about the end of civilization. But you can also understand for a society that had in recent memory ported over all of its most essential operations onto digital computer systems, how a failure in that system could be seen as

being beaten times. I mean that parts understandable, right, especially if you don't have a deep knowledge of how computers work. To you, it could just be a mystery and it just means that all your stuff stops working the next day. That's a pretty terrifying prospect. As we know, it wasn't necessarily accurate, but that doesn't mean the Y two K problem was not a problem. It certainly was. I hope

that you enjoyed this episode. Will be back later this week with some tech news and a new Smart Talks episode, and if you have any suggestions for topics I should cover in future episodes of tech Stuff, reach out to me on Twitter. The handle for the show is tech Stuff h s W and I'll talk to you again really soon. Tech Stuff is an I Heart Radio production. For more podcasts from My Heart Radio, visit the i Heart Radio app, Apple podcast wherever you listen to your favorite shows.