Speaker 1: Welcome to Tech Stuff, a production from I Heart Radio.
Speaker 1: Hey there, and welcome to tech Stuff. I'm your host,
Speaker 1: Jonathan Strickland. I'm an executive producer with I Heart Radio,
Speaker 1: and I love all things tech. And if you are
Speaker 1: in your early twenties or you are younger than that,
Speaker 1: you missed out on a pretty big deal in tech.
Speaker 1: And that's the Y two K problem. So Y two
Speaker 1: K stands for the year two thousand and by the way,
Speaker 1: there's somewhat of a delicious irony at work here, because
Speaker 1: Y two K is a way for us to shorten
Speaker 1: the year two thousand and the Y two K problem
Speaker 1: itself stems from our tendency to shorten stuff for the
Speaker 1: sake of convenience, even at the expense of long term results.
Speaker 1: But I digress. By the late ninety nineties was this
Speaker 1: growing concern that a great deal of the technology that
Speaker 1: we rely upon was just going to fail on the
Speaker 1: stroke of midnight. As New Year's Eve n turned to
Speaker 1: New Year's Day two thousand, people were worried about everything
Speaker 1: from toasters to airplanes that we're all gonna just fail spontaneously,
Speaker 1: and clearly the latter would have a much more catastrophic
Speaker 1: result than the former. So today I thought I would
Speaker 1: really go through what was happening with the HYE two
Speaker 1: K problem, how various companies tried to solve it, and
Speaker 1: what actually happened at the turn of the millennium. Uh,
Speaker 1: that last bit I should probably back off of, since
Speaker 1: you know two thousand was actually the end of the millennium.
Speaker 1: Two thousand one would have been the beginning of the millennium.
Speaker 1: Don't at me. Years don't start at zero, we start
Speaker 1: at one. So that means one to one hundred would
Speaker 1: be the first century, one oh one to two d
Speaker 1: would be the second. That that's my stance. You might disagree.
Speaker 1: Let's just agree to disagree and go our separate ways.
Speaker 1: But I'll also talk about some related issues in tech,
Speaker 1: including how the Y two k problem resurfaced just last year,
Speaker 1: because that actually did happen, and there's there's a reason
Speaker 1: for it, and that reason is kind of tragically funny. Now,
Speaker 1: the easiest thing to do here is to just summarize
Speaker 1: the whole issue in this way. The Y two K
Speaker 1: problem emerged because of a convergence of several factors. Factor
Speaker 1: number one is that computer memory is finite. It has
Speaker 1: a limit. Factor number two is that we often build
Speaker 1: on top of what came before, meaning the stuff we
Speaker 1: create twenty years ago becomes the foundation for the stuff
Speaker 1: that we create today. And factor number three is that
Speaker 1: sometimes people are lazy. Even if they have the resources
Speaker 1: to do more than what was capable in the past,
Speaker 1: they may just still do the bare minimum. Alright, And
Speaker 1: because the world did not go up in flames when
Speaker 1: the calendar switched from two thousand, many people assume that
Speaker 1: the whole brew haha was over nothing. But it wasn't nothing.
Speaker 1: Companies had spent billions of dollars, hundreds of billions of
Speaker 1: dollars to address the issue. They were reconfiguring systems, they
Speaker 1: were updating code in order to avoid the problem. Some
Speaker 1: of them really just punted the problem a little bit
Speaker 1: into the future. And even today, we still occasionally have
Speaker 1: instances in which an antiquated system or piece of software
Speaker 1: generates an incorrect result because of the y u K bug,
Speaker 1: though that sort of thing never really makes the news
Speaker 1: these days. After all, a computer producing an error isn't
Speaker 1: really newsworthy unless something particularly catastrophic results because of that, right,
Speaker 1: So let's get to the root of it. In the
Speaker 1: early days of computer programming for companies and organizations, you know,
Speaker 1: when programming was moving out of like the research labs
Speaker 1: and the military institutions. So we're talking about like the
Speaker 1: nineteen sixties here. Computer memory was a really precious resource.
Speaker 1: There just wasn't a whole lot to work with, so
Speaker 1: programmers would try and cut corners wherever possible, trying to
Speaker 1: make code in an efficient and effective way. And one
Speaker 1: decision a lot of coders made in those early days
Speaker 1: was to take a bit of a shortcut when it
Speaker 1: came to designated the year. Rather than using a four
Speaker 1: digit designation for the year, like you know nineteen sixty one,
Speaker 1: programmers often shorten the year down to the last two digits,
Speaker 1: and heck, to be fair, we humans, we do this
Speaker 1: all the time in casual conversation as well as Brian
Speaker 1: Adams songs or for those of you post two thousand
Speaker 1: babies bowling for soup songs. So nineteene seventy five just
Speaker 1: becomes seventy five. Computers would just assume that the two
Speaker 1: unincluded digits would be one nine, So the two digit
Speaker 1: year designation was with the assumption that this year fell
Speaker 1: somewhere in the century of nineteen hundred to nineteen Well,
Speaker 1: I shouldn't say century, the one hundred year period between
Speaker 1: nineteen hundred and nine. No need to go back on
Speaker 1: that nineteen o one thing, And at the time that
Speaker 1: was okay. There were still decades left in the nineteen hundreds.
Speaker 1: While this computer programming was going on. Computer memory was
Speaker 1: bound to improve, and surely the future programmers would move
Speaker 1: to a four digit designation for the year once they
Speaker 1: had the elbow room to do it. Now, to be clear,
Speaker 1: this problem was not a new one. In fact, you
Speaker 1: could argue that this problem actually dates back to before
Speaker 1: there were computers. So let us take a journey all
Speaker 1: the way back to eighteen eighty one. You probably didn't
Speaker 1: think the Y two K problem dates all the way
Speaker 1: back beyond a century before the pivotal event. Huh. But
Speaker 1: eight eight one, or really eighteen eighty was a census
Speaker 1: year here in the United States, and the US holds
Speaker 1: a census every ten years. Now, the one in eighteen
Speaker 1: eighty presented a particular challenge that was evident by eighty one.
Speaker 1: So that was that it was going to take a
Speaker 1: long time to tabulate all the results of that census
Speaker 1: in fact, Ultimately, it took eight years to tabulate the
Speaker 1: results of the eighteen eighties census, and this is something
Speaker 1: that is to happen every ten years, right. And meanwhile,
Speaker 1: in the United States, population was growing, and it was
Speaker 1: pretty much a guarantee that the next census was going
Speaker 1: to take even longer to tabulate unless there was some
Speaker 1: sort of major change. And then along came a fellow
Speaker 1: by the name of Herman hollerith and engineer with a
Speaker 1: goal to create a machine capable of tallying census results automatically.
Speaker 1: He was building upon Joseph Maria Jacquard's invention the punch card. Now,
Speaker 1: Jacquard used punch cards to guide looms as in weaving machines.
Speaker 1: These these punch cards automated the weaving of certain patterns,
Speaker 1: so that these intricate patterns that would normally take a
Speaker 1: very long time to do by hand, could be done
Speaker 1: very quickly through the use of these punch cards. Holler
Speaker 1: has saw this as a way to designate results on
Speaker 1: a census response. You would have a clerk who would
Speaker 1: take a response. They would punch some holes into a
Speaker 1: punch card that would represent those responses, and then feed
Speaker 1: those two tallying machines that could tabulate the results quickly.
Speaker 1: So Hollow designed cards that measured seven inches by three inches,
Speaker 1: capable of holding just eighty characters total. Now, if you
Speaker 1: only have eighty characters to work with, every character is precious,
Speaker 1: So using four of those eighty characters to designate a
Speaker 1: year would be pure luxury. And so you decide you're
Speaker 1: gonna cut a corner. You're just going to use the
Speaker 1: last two digits of the year instead of the whole thing. Um,
Speaker 1: if anyone's used Twitter back when it was at a
Speaker 1: hundred forty characters, you know, like once you started getting
Speaker 1: close to those hundred forty characters, he had to rethink
Speaker 1: your message as and how can I how can I
Speaker 1: make this more concise so that I can get across
Speaker 1: my meaning? Well, the same sort of thing here. Now,
Speaker 1: that was for nineteenth century punch cards, which, by the way,
Speaker 1: that actually did work. The nine senses took two years
Speaker 1: to tabulate compared to the eight years of the eighty
Speaker 1: cents is but that need to conserve precious memory space
Speaker 1: persisted well into the twentieth century. The prevailing thought was
Speaker 1: that computer memory would improve over time and would eliminate
Speaker 1: the need to be so frugal with the programming code.
Speaker 1: But then people didn't really bank on something called Worth's law.
Speaker 1: That's w I R t H. Now in the tech world,
Speaker 1: there are a few observations that we've collectively decided to
Speaker 1: call laws. Arguably the most famous one is Moore's law.
Speaker 1: That's based on an observation made by Gordon Moore, and
Speaker 1: his observation centered more on the trend of the doubling
Speaker 1: of the number of transistors on integrated circuit every two years.
Speaker 1: Actually gets a little more persinkty than that it brings
Speaker 1: in market pressures and finance and things. But that's a
Speaker 1: decent summary. But these days we typically say that Moore's
Speaker 1: law is a trend in which computers double in processing
Speaker 1: power and or speed every two years, so that the
Speaker 1: computer you buy two years from today will be twice
Speaker 1: as powerful as the one you are currently using. Assuming
Speaker 1: the one you're currently using as a new computer. Well,
Speaker 1: Worth's law is a little bit different. Nicholas Worth wrote
Speaker 1: in an article in n It was an article titled
Speaker 1: a Plea for Lean Software that software was placing greater
Speaker 1: demands on hardware at a rate that was even faster
Speaker 1: than Moore's law. So, in other words, software was requiring
Speaker 1: more processing power than computers could easily provide. And that's
Speaker 1: even taking into account the incredible growth rate of Moore's law.
Speaker 1: Programmers were not being efficient and companies were eager to
Speaker 1: throw in all the possible bells and whistles and programs
Speaker 1: to attract customers. And when you're trying to build in
Speaker 1: the capability for your word processor to also play video files,
Speaker 1: for some reason, you might not have the room to
Speaker 1: also use four digits to mark the year. You cut
Speaker 1: corners where you can so. Ironically, while computer memory would
Speaker 1: improve and in theory allow for a change from the
Speaker 1: two digit year format to a four digit year format,
Speaker 1: a lot of programmers just didn't take that route. Whether
Speaker 1: it was because they had fallen into a habit and
Speaker 1: they just used two digits because this is how we've
Speaker 1: always done it, or because they literally wanted to save
Speaker 1: that space for something else, just comes down to a
Speaker 1: case by case basis. Also, hey, quick side note, the
Speaker 1: argument we do it this way because we've always done
Speaker 1: it this way is a dumb argument. Now it could
Speaker 1: be that the old way is the best way that
Speaker 1: would be totally valid. If it is in fact the
Speaker 1: best way, sure keep doing it. You're not doing it
Speaker 1: because that's the way you've always done it, but because
Speaker 1: that's the best way to do it. But to only
Speaker 1: do things one way, because that quote is how it's
Speaker 1: always been done, en quote, is more often than not
Speaker 1: an impediment to progress. Anyway, let me get back to
Speaker 1: the story now. Part of the story is also about
Speaker 1: standards and why we have them and why it's so
Speaker 1: darn frustrating when we refuse to actually use um when
Speaker 1: it comes to expressing dates and time. There is an
Speaker 1: international standard we could follow, and it goes like this,
Speaker 1: four digits for the year, then two digits for the month,
Speaker 1: then two digits for the day, than two digits for
Speaker 1: the hour, two digits for the minutes, two digits for
Speaker 1: the seconds. And if you followed that then there would
Speaker 1: never be any confusion. Uh. This provides a precise way
Speaker 1: to document the specific time, and if we had relied
Speaker 1: on such a standard, then the Y two K problem
Speaker 1: wouldn't have been a problem at all. Of course, that
Speaker 1: would have required us to have the computer memory available
Speaker 1: to use that standard every time. We needed to have
Speaker 1: a year in the code, but it would actually work.
Speaker 1: And uh, you know, sometimes we just don't incorporate standards
Speaker 1: because incorporating standards requires effort, and you know, sometimes it's
Speaker 1: just not feeling it that day. You know, you get
Speaker 1: up and you're like, you know, I I just don't
Speaker 1: feel like living up to standards. I certainly can identify
Speaker 1: with that on a personal level. Well as early as
Speaker 1: the nineteen eighties, some programmers began to wonder about issues
Speaker 1: that might come up closer to the New millennium. In fact,
Speaker 1: there were some industries that were already dealing with this,
Speaker 1: but we'll get into that a bit later. This was
Speaker 1: more about people actually using publications to talk about this issue.
Speaker 1: So if a computer is looking at dates as two
Speaker 1: digit numbers, what happens when goes to zero zero? Let
Speaker 1: me tell you a quick story about a pinball machine
Speaker 1: that used to play back when I was in college.
Speaker 1: I promise this relates. And also I just love pinball
Speaker 1: and it's one of my favorite stories. I went to
Speaker 1: the University of Georgia and at you g A's student center,
Speaker 1: we had a game room that included a row of
Speaker 1: pinball machines and they were also about two dozen and
Speaker 1: arcade games, and the pinball machines included some true classics
Speaker 1: like Adam's Family, which is to date my favorite pinball
Speaker 1: machine of all time. Twilight Zone another great, very difficult
Speaker 1: pinball machine. But once in a while we would also
Speaker 1: have someone rotate in a new or sometimes a very
Speaker 1: old pinball machine, and I suppose they must have belonged
Speaker 1: to some you know, alumnus is private collection or something. Anyway,
Speaker 1: at one point, for some reason, we got a nineteen
Speaker 1: seventy nine Star Trek pinball machine from Bally and just
Speaker 1: so y'all know, I was in college in the nineties,
Speaker 1: so this was a vintage pinball machine even back then.
Speaker 1: The playing field on this machine had this one little
Speaker 1: button in the floor of the playing field up at
Speaker 1: the top left part, and it was designed so that
Speaker 1: when the pinball would roll over it, it would activate
Speaker 1: the button. And this button was in charge of activating
Speaker 1: an extra ball after it has hit a certain number
Speaker 1: of times. However, this particular machine had a button that
Speaker 1: would stick a little bit, so it didn't take very
Speaker 1: much effort to get that extra ball, and I, being
Speaker 1: the enterprising sort pun intended because of Star Trek, I
Speaker 1: decided one day that. You know, I didn't have any
Speaker 1: classes that day. I was going to use this knowledge
Speaker 1: to my advantage, and my goal was at the beginning
Speaker 1: of each play just just focus on getting the ball
Speaker 1: up in that upper left part of the playfield and
Speaker 1: to activate the extra ball. That was goal number one.
Speaker 1: Once I did that, from that point forward, I could
Speaker 1: just play the game. I could do whatever I wanted
Speaker 1: because I had an extra ball already, and even if
Speaker 1: the ball drained, I wouldn't lose a life because that
Speaker 1: was the extra ball. And as soon as I started
Speaker 1: playing the extra ball, I would do it all over again.
Speaker 1: And this meant that as long as I could get
Speaker 1: it up into that upper left part of the game,
Speaker 1: I could effectively play this game forever or until I
Speaker 1: was exhausted. Well, the score of this particular machine could
Speaker 1: only accommodate up to a certain number of digits, and
Speaker 1: I can't remember what it was. Let's say it was
Speaker 1: a million or just under a million. So I decided
Speaker 1: I wanted to see what would happen if I exceeded
Speaker 1: that number. I had the methodology there, and sure enough,
Speaker 1: when I got to that point, you know whatever, it
Speaker 1: was like nine thousand, nine nine or whatever. I saw
Speaker 1: that the next point, the next thing that I hit
Speaker 1: that generated points sent me back over to the zero
Speaker 1: starting point, and the score keeping started over. So satisfied
Speaker 1: that I had turned over the machine, I had rolled
Speaker 1: over the score, I quickly finished out the game, and
Speaker 1: I wanted to see if it would let me set
Speaker 1: a high score, or if it would, you know, choose
Speaker 1: my score as the high score. It did not. It
Speaker 1: reverted back to the previous high score that was technically lower. Um.
Speaker 1: So there was a rollover problem. In other words, like
Speaker 1: once it hit zero, the computer interpreted that to mean
Speaker 1: that we were back at ground zero. Well, in the
Speaker 1: early eighties, a few programmers were starting to worry that
Speaker 1: a lot of systems in software had a similar rollover
Speaker 1: problem and it was going to all come to a
Speaker 1: head in two thousand. With the two digit designation for years,
Speaker 1: it could mean that computer systems would think the year
Speaker 1: was starting back over at zero and work up to
Speaker 1: a maximum before rolling over again. And this could potentially
Speaker 1: be a big problem. So, for example, let's say you
Speaker 1: were a go getter in and you got yourself one
Speaker 1: of them fancy credit cards, and your credit cards expiration
Speaker 1: date is in let's say two thousand two, and then
Speaker 1: you go out and you take your fancy credit card
Speaker 1: to buy you and someone special, you know, a really
Speaker 1: nice meal, and you've got, you know, plenty of credit
Speaker 1: on your card. Everything should be fine. Only when the
Speaker 1: fancy restaurant runs your credit card, the underlying retail system
Speaker 1: detects and error. The system is attempting to verify that
Speaker 1: your card is valid, so it checks the expiration date,
Speaker 1: but it's essentially saying, you know, is today's date before
Speaker 1: or after the expiration date on this card. If today's
Speaker 1: date is before the expiration date, everything's fine. If it's after,
Speaker 1: that's a problem. And if the system was using a
Speaker 1: two digit year designation, it would say, oh, zero two
Speaker 1: is less than That means this card expired like ninety
Speaker 1: seven years ago, and the transaction would get declined. This
Speaker 1: really happened a lot. Now that's just a sample scenario
Speaker 1: of something that could happen, the sort of you know,
Speaker 1: tiny thing that would be inconvenient on an individual basis.
Speaker 1: But it was just the tip of the iceberg for
Speaker 1: possible problems. I'll talk about it more when we come
Speaker 1: back after this break. I mentioned a small scale problem
Speaker 1: the one that's you know, huge when you apply it
Speaker 1: to the entire population. But how about something that's even
Speaker 1: bigger than that, And let's stick with the financial world
Speaker 1: and talk about banks. So let's say it's nineteen eighty
Speaker 1: five when you establish a savings account and you put
Speaker 1: some money in the account and it begins to earn
Speaker 1: interest at a certain percentage per year. And the way
Speaker 1: the bank system determines this is by taking the current
Speaker 1: year let's say, in this scenario, the current years, and
Speaker 1: then you subtract from that the year in which you
Speaker 1: established your account. So in this example, it would be
Speaker 1: nine eighty five. That gives us ten that's ten years
Speaker 1: of earning interest, which then can be calculated and then
Speaker 1: you know how much interest you've earned on your account,
Speaker 1: which is pretty simple. But let's say instead, now it's
Speaker 1: the year two thousand, and you're still using these two
Speaker 1: digit year designations, and now the bank system is trying
Speaker 1: to subtract from zero zero. Now, remember the system is
Speaker 1: assuming that both of these are happening in the century
Speaker 1: or the one years between ninet So now the figure
Speaker 1: it comes up with is negative eight five, and that
Speaker 1: means that you've earned negative interest which gets pulled from
Speaker 1: your account, it overdraws your account. So the real concern
Speaker 1: was that the Y two K bug was going to
Speaker 1: lead to numerous computer systems, particularly in the financial world,
Speaker 1: but not exclusively there, and it was going to cause
Speaker 1: them to miscalculate things like this, and as a result,
Speaker 1: you would have widespread system failures. Accounts could get wiped out,
Speaker 1: insurance policies could get canceled, mortgages could be flagged for foreclosure,
Speaker 1: and so on. It would be catastrophic and a huge
Speaker 1: headache to clean up, and all because we had migrated
Speaker 1: to computer systems that we're using a two digit format
Speaker 1: for the year. A few people became aware of this
Speaker 1: pretty early on, but it took a surprisingly long time
Speaker 1: for the concern to kind of filter out beyond a
Speaker 1: small collective. The problem extended well beyond the financial industry.
Speaker 1: Anything that was dependent upon a year, even something as
Speaker 1: simple as sorting a group of files chronologically, started to
Speaker 1: fall apart. If the computer systems interpreted two thousand as
Speaker 1: really being nineteen hundred, it could affect navigation systems, communication systems,
Speaker 1: and all sorts of other industries. Now, from what I
Speaker 1: can tell, people began to see this as an issue
Speaker 1: UH and started talking about it beyond internal groups around
Speaker 1: the early nineteen eighties, but didn't get much attention. Back then.
Speaker 1: Some companies like IBM were probably more aware of it.
Speaker 1: I mean, the company certainly claimed as much, but they
Speaker 1: kept those discussions for the most part internal, so the
Speaker 1: outside world wasn't really aware of it. In nineteen eight six,
Speaker 1: Bruce Olmes wrote an article in the IBM Systems Journal,
Speaker 1: Volume twenty five, issue two. It has the title computer
Speaker 1: processing of Dates outside the twentieth century, and in this article,
Speaker 1: Olms points out that there's a need for a different
Speaker 1: approach than this two digit year designation. Omas's solution was
Speaker 1: to use the Lilian date format, which was his own proposal.
Speaker 1: This format actually takes the date of the formation of
Speaker 1: the Gregorian calendar, which was October four two, and thus
Speaker 1: designates October two as date one. So the date of
Speaker 1: the creation of the Gregorian calendar is zero, The next
Speaker 1: day would be one, the day after that would be two,
Speaker 1: and so the format goes up one per each day
Speaker 1: after that date. That would make today's date one hundred
Speaker 1: sixty thousand, two hundred sixty two today, by the way,
Speaker 1: being July one, in case you're listening from the future.
Speaker 1: Olms also suggested an approach that would use windows of
Speaker 1: time to try get around the two digit problem, generally
Speaker 1: speaking for modern systems that weren't dealing with dates and antiquity.
Speaker 1: He was suggesting that for any years designated as fifty
Speaker 1: or lower, we assume that those are for the year
Speaker 1: two thousand, and for any years fifty one or higher,
Speaker 1: we assume that those are for the year nineteen hundreds.
Speaker 1: So with a little coding, the computer system interprets any
Speaker 1: two digit year number above fifty one to belong in
Speaker 1: the nineteen hundreds. Any two digit year belonging below fifty
Speaker 1: belongs in two thousand's. So if the year was listed
Speaker 1: as seventy seven, then it would mean it's nineteen seventy seven,
Speaker 1: But if it were listed as thirty three, it would
Speaker 1: be two thousand thirty three. So he was proposing this
Speaker 1: as a stop gap solution because it only lasts as
Speaker 1: long as whatever you're dividing year is, and we'll get
Speaker 1: back to that. And this would end up being a
Speaker 1: pivotal part of many companies Y two K strategies, which,
Speaker 1: as we'll see, as part of a problem. Ohms also
Speaker 1: pointed out how simple the problem was in concept, but
Speaker 1: how complicated it was in practice. Conceptually, the only thing
Speaker 1: anyone really has to do is go in and change
Speaker 1: a tiny bit of code and a file. So on
Speaker 1: an individual file basis, it was trivial. It was incredibly simple.
Speaker 1: You could do it in a in just a few minutes.
Speaker 1: But of course reality is way more complicated, because in
Speaker 1: reality we have suites of software that all connect to
Speaker 1: one another, and a change in one of those has
Speaker 1: consequences for everything else that connects back to it. The
Speaker 1: interconnectedness of software requires that for these systems, all of
Speaker 1: these changes to the way that we designate years really
Speaker 1: needs to happen simultaneously across all software, or else you're
Speaker 1: gonna have issues with compatibility. Now, at this point, you're
Speaker 1: not talking about just go into a bunch of individual files,
Speaker 1: even like millions of them, and changing a couple of numbers.
Speaker 1: You're talking about trying to keep an entire software ecosystem
Speaker 1: stable while you do it, and so you don't interrupt
Speaker 1: the daily operations, and you also, you know, fix the
Speaker 1: underlying issue. That's a non trivial problem. So Ohams writes,
Speaker 1: this piece for IBM and lays out the challenge and
Speaker 1: the two digit year format is likely to cause at
Speaker 1: least some problems as the year rolls over from ninety
Speaker 1: nine to zero zero. And the scale of the problem
Speaker 1: for large systems is daunting. It will require a lot
Speaker 1: of time and effort to address with a careful approach
Speaker 1: so as not to disrupt normal operations. And this is
Speaker 1: in n when he writes this, so you would think, oh, well,
Speaker 1: that gives you plenty of time to fix things, right,
Speaker 1: I mean, you've got fourteen years. And it means that
Speaker 1: people working on the next generation of software products and
Speaker 1: systems can just avoid the problems of the past, right
Speaker 1: and just use a four digit year from that point forward. Well,
Speaker 1: obviously that didn't happen quite like that. Olams's article and
Speaker 1: IBMS publication of that article acknowledged that there was an
Speaker 1: underlying problem in software and computer systems, but the article
Speaker 1: didn't really go so far as to define the scale
Speaker 1: of the problem nor the amount of work and money
Speaker 1: it would require to address the problem. But it certainly
Speaker 1: established that, y'all, we got a problem. That problem was
Speaker 1: one with a specific countdown every moment that passed would
Speaker 1: bring us closer to January one, two thousand. It was,
Speaker 1: as many people would describe later, a technical time bomb. Now,
Speaker 1: from what I can tell, the first person to actually
Speaker 1: describe the rollover problem as a time bomb was Chris Anderson,
Speaker 1: who published a half page advertisement in the South African
Speaker 1: journal Computing back in June of six. And the top
Speaker 1: of the ad read the time bomb in your IBM
Speaker 1: mainframe system. And I'll just read you a small part
Speaker 1: of the copy for that ad quote the date time bomb.
Speaker 1: The cause is that no IBM mainframe operating system software
Speaker 1: or compiler properly caters for a date subsequent to December
Speaker 1: thirty one. The hardware can cope, but the main system
Speaker 1: software has a bug. Vmsp vs, e v S e S,
Speaker 1: p m vs all have the same glitch. This is
Speaker 1: also true for the compiler's cobal assembler at al end quote.
Speaker 1: So Anderson's message continued and issued warnings against investing in
Speaker 1: companies that rely on outdated systems and making certain that
Speaker 1: you know your affairs are all in order before two thousand,
Speaker 1: that your money's in a safe place, that kind of thing,
Speaker 1: And he paints a pretty bleak worst case an areo
Speaker 1: in this ad, which you know you could go back
Speaker 1: and argue and say all of this is is true.
Speaker 1: If nothing were to be done like this could have
Speaker 1: been a pretty catastrophic event at least one that would
Speaker 1: have been incredibly disruptive for more than a month at least.
Speaker 1: And he ends his ad with a reveal that he's
Speaker 1: setting up a group called Deadline two thousand to investigate
Speaker 1: and and and coordinate implementation of immediate solutions to this problem. Now,
Speaker 1: IBM responded to this, and in that response, a company
Speaker 1: rep argued that it had already anticipated this problem and
Speaker 1: in fact had taken steps to mitigate it, which changes
Speaker 1: to hardware architecture and updated software that uses four digits
Speaker 1: to designate the year, thus sidestepping the two digit problem. Further,
Speaker 1: the company said that there are some legacy systems that
Speaker 1: cannot be upgraded and updated to this this format, but
Speaker 1: these are limited and work around could follow. And essentially
Speaker 1: IBM was saying, this is not the big deal that
Speaker 1: Anderson says it is, and we think he's just trying
Speaker 1: to drive up business for his consulting company. Now, IBM
Speaker 1: was a really big advertiser with this particular magazine, and
Speaker 1: perhaps coincidentally, the magazine failed to carry any other deadline
Speaker 1: two thousand notices moving forward. And by perhaps coincidentally, I
Speaker 1: mean almost certainly not coincidentally. IBM's response did acknowledge that
Speaker 1: some legacy systems like disc directories and tape labels wrote
Speaker 1: alied on the two digit year designation, and that these
Speaker 1: could conceivably cause problems for people down the line if
Speaker 1: they never address that problem. I bet you can't guess
Speaker 1: what happened next, you know what. I'll tell you what
Speaker 1: happened next in just a moment. But first, let's take
Speaker 1: another quick break, all right. I mentioned before the break
Speaker 1: that a big part of this had to do with
Speaker 1: tape files, and we're talking about magnetic tape here, the
Speaker 1: physical medium of storage that we used way back in
Speaker 1: the day to store information. And some of you might
Speaker 1: have even had experiences with magnetic tape, whether I mean
Speaker 1: it could have been cassette tapes. Those are magnetic tape
Speaker 1: as well. Those are used for for audio, but uh,
Speaker 1: some old computers used cassette tapes. Personally, I've had experience
Speaker 1: with magnetic tape because at one point I was working
Speaker 1: with a consulting firm where part of my job involved
Speaker 1: making sure that the company's files went to tape back
Speaker 1: up at the end of each night. So the idea
Speaker 1: was any file that had been changed during that day
Speaker 1: needed to go into a backup, and I regularly would
Speaker 1: have to switch out reels of tape and store the
Speaker 1: older ones away just in case someone needed a version
Speaker 1: of a proposal from you know, I don't know, five
Speaker 1: years a go or something, which, to be fair, did
Speaker 1: occasionally happen. Now. As part of making tape files, administrators
Speaker 1: would assigned to each a file, each file and expiry date,
Speaker 1: so essentially beyond that date, the file would be seen
Speaker 1: as being invalid, something that a system could overwrite without
Speaker 1: an issue because the data in that file is no
Speaker 1: longer relevant and it goes into what was essentially called
Speaker 1: a scratch directory, meaning it's it's ready to be overwritten.
Speaker 1: But this meant that if you were to try and
Speaker 1: insert one of these scratch tapes into a system, rather
Speaker 1: than pulling data off of that tape, the system would
Speaker 1: just overwrite the data on the tape. So anything that
Speaker 1: was on the tape, even if it was valuable and relevant,
Speaker 1: the system would erase because it was beyond that expiry date.
Speaker 1: That was a real issue was that, you know, with
Speaker 1: this two digit format, once you go to zero zero,
Speaker 1: there was a worry that all of this stuff that
Speaker 1: was being stored on magnetic tape would just be marked
Speaker 1: to be erased the next time it was put in use.
Speaker 1: So the time bomb in this case would be the
Speaker 1: tape files that would definitely expire by the beginning of
Speaker 1: two thousand due to that two digit date designation, but
Speaker 1: IBM wasn't too concerned about this at the time because
Speaker 1: there were fourteen years left to go. Complicating matters is
Speaker 1: that these discussions were happening in a pre Worldwide Web environment,
Speaker 1: which meant that the forums for these discussions were typically
Speaker 1: computer magazines, and those, by their very nature have a
Speaker 1: fairly niche and limited audience. That meant that the folks
Speaker 1: having these discussions made up a very tiny sliver of
Speaker 1: the population, and usually it didn't include people who had
Speaker 1: decision making authority at higher levels within various organizations including
Speaker 1: companies and governments. So the folks who really needed to
Speaker 1: know about this, you know, the executives who are in
Speaker 1: charge to big institutions like financial companies or airlines or
Speaker 1: what have you largely remained ignorant of the impending issue
Speaker 1: until it became undeniable and you know, a critical, acute problem.
Speaker 1: So then we get to the early nineteen nineties and
Speaker 1: the birth of the Worldwide Web. That invention would make
Speaker 1: it possible for, you know, to to issue communications on
Speaker 1: a much more broad scale and allow individuals to spread
Speaker 1: the word about things much more effectively. And now stuff
Speaker 1: that might have been buried in a few inches of
Speaker 1: column space in a magazine could get the same spotlight
Speaker 1: as major news. At least in theory, people still needed
Speaker 1: to be able to find that respective web page and
Speaker 1: then read it and all that kind of stuff, but
Speaker 1: the potential to spread information quickly became a really big deal.
Speaker 1: In ninete, Peter di Yeager wrote a couple of articles
Speaker 1: about the rollover problem. The first was in a Canadian
Speaker 1: computer magazine with a relatively small circulation. That article received
Speaker 1: a fairly derisive response from the Globe and Mail, a
Speaker 1: national newspaper in Canada that really downplayed the scope and
Speaker 1: impact of the problem. The second article, published in Computer World,
Speaker 1: had the sensational title Doomsday two thousand, a title that
Speaker 1: Dieger says he did not pitch, but was rather assigned
Speaker 1: by an editor to that piece, and that ended up
Speaker 1: getting a little bit more attention. But even then, even
Speaker 1: people that Dieger was associating with, who were in the
Speaker 1: I T world, even they didn't seem terribly concerned at
Speaker 1: that point. Now, while much of the focus on the
Speaker 1: Y two K problem really centered on the years n
Speaker 1: you know, when it was imminent, that's when organizations and
Speaker 1: companies were feverishly trying to fix their back end systems
Speaker 1: in software to avoid catastrophe. There were earlier cases of
Speaker 1: groups kind of coming to grips with it, just they
Speaker 1: were doing so quietly on an individual basis, which wasn't
Speaker 1: too helpful for everybody else. For example, I mentioned mortgages earlier.
Speaker 1: A common mortgage length is a thirty year mortgage, which
Speaker 1: meant that back in the nineteen seventies, banks and credit
Speaker 1: unions were starting to put together mortgages that would terminate
Speaker 1: in the early two thousands, and these financial institutions discovered
Speaker 1: that the software they were using to determine things like
Speaker 1: mortgage payments and such, we're having problems because of the
Speaker 1: rollover issue. So they were already seeing the effects of
Speaker 1: the Y two K problem back in the nineteen seventies
Speaker 1: because they were projecting out beyond the year two thousand,
Speaker 1: and that's where they were seeing that their software was
Speaker 1: was sputtering. By the nineteen nineties, as I mentioned, we
Speaker 1: started seeing those those credit card examples that I gave
Speaker 1: you earlier. People would get a new credit card in
Speaker 1: the nineties that would have an expiration in the early
Speaker 1: two thousands, and then discovered that the card processing systems
Speaker 1: at various retail establishments were generating a card expired error
Speaker 1: error code even though the actual expiration date was in
Speaker 1: the future, but to the computers that look like it
Speaker 1: was in the distant past. So in these cases, the
Speaker 1: financial institutions like the mortgage companies on one hand, and
Speaker 1: then the retail companies on the other hand, all created
Speaker 1: problem fixes to kind of work around these these problems.
Speaker 1: But these were isolated incidents of companies and organizations taking
Speaker 1: the steps necessary to fix or at least sidestep this problem.
Speaker 1: In the short term, the world at large was still
Speaker 1: under prepared, which is one of the big issues with
Speaker 1: the Y two K problem. It wasn't just that the
Speaker 1: problem was serious, it was that as people were encountering it,
Speaker 1: they were readily sharing that with other companies and other organizations,
Speaker 1: which meant that everyone was having to go through it
Speaker 1: kind of individually, and it was not the most efficient
Speaker 1: way to tackle a problem. So there was the sort
Speaker 1: of hatch work awareness going on. Companies that had any
Speaker 1: sort of programs that would project results into the future
Speaker 1: were likely to run up against the Y two K
Speaker 1: problem at some point. If the company had either a
Speaker 1: product or some internal system that made projections, and if
Speaker 1: that system relied in whole or in part on a
Speaker 1: two digit representation of the year, there was a good
Speaker 1: chance that someone noticed something hinky was going on, that
Speaker 1: programs were not behaving the way they were supposed to.
Speaker 1: But it wasn't until nine in the United States when
Speaker 1: Congress passed the Year two thousand Information and Readiness Disclosure
Speaker 1: Act and President Clinton signed it into law. The law's
Speaker 1: purpose was to encourage companies to share their Y two
Speaker 1: K strategies and in return receive limited liability coverage. The
Speaker 1: hope was that companies that had found successful workarounds could
Speaker 1: share those methods with others and speed up the process
Speaker 1: of getting everyone on the right track. Essentially, to address
Speaker 1: this issue of every on kind of going it alone,
Speaker 1: and they're not being established best practices and workarounds. This
Speaker 1: also included state and federal government offices. These were lagging
Speaker 1: way behind the private sector. There was a survey done
Speaker 1: in ninety eight that showed that the government in the
Speaker 1: United States was far behind the private sector world, you know,
Speaker 1: private companies and publicly traded companies. So out of this
Speaker 1: grew a new industry. You had consultants who would come
Speaker 1: on board to try and bring an organization into Y
Speaker 1: two K compliance, which essentially meant just addressing any gaps
Speaker 1: that would cause the sort of mis interpretation of the
Speaker 1: year on the part of computer systems. The big stop
Speaker 1: gap measure, as I mentioned, was windowing, that is, creating
Speaker 1: a way for a computer system to interpret two digits
Speaker 1: as being four digits. And again I mentioned it earlier
Speaker 1: in this episode, and it works well enough for any
Speaker 1: processes that you know originate in the twentieth century, But
Speaker 1: if you go back further you run into problems as
Speaker 1: the whole thing repeats itself again. But since computers and
Speaker 1: software weren't really a thing back before nineteen six, generally
Speaker 1: it was considered a non issue and an effective stop gap.
Speaker 1: Making these changes proved to be time consuming and expensive.
Speaker 1: The world at large spent hundreds of billions of dollars
Speaker 1: to update code and get things on track for the
Speaker 1: change to two thousand. In that process, the media reported
Speaker 1: on the issue in a way that one could be
Speaker 1: forgiven to describe as hyperbolic. Now, as I've mentioned in
Speaker 1: this episode, there was a very real problem, like a
Speaker 1: host of very real problems that could arise as a
Speaker 1: result of the rollover, and we, in fact we did.
Speaker 1: We saw this happening with mortgages and credit cards, like
Speaker 1: there was definitive proof that this is an issue. The
Speaker 1: problems were not imaginary, and in many cases they were
Speaker 1: not trivial. I've seen some blog posts that have been
Speaker 1: written over the last few years that kind of ridicule
Speaker 1: how people were preparing for Y two K, and it
Speaker 1: trivializes the scope and the reach of the problem, And
Speaker 1: I think that's about as irresponsible as over exaggerating the
Speaker 1: effects of the problem. But anyway, some of the cynical
Speaker 1: response is understandable because media outlets were talking about how
Speaker 1: to stockpile necessities like food and water and toiletries and
Speaker 1: cash just in case the financial systems and payment systems failed,
Speaker 1: and as I mentioned before, we had seen them fail
Speaker 1: in the past. So the idea was that people should
Speaker 1: have a cushion to get them through the worst of
Speaker 1: it and wait for solutions to arise. But some media
Speaker 1: outlets took this to an extreme and it began to
Speaker 1: sound a bit like stockpiling a bunker for protection for
Speaker 1: like nuclear fallout or something, and that the very fabric
Speaker 1: of society would break down and we'd all live in
Speaker 1: the walking debt. There were fears of elevators stopping between
Speaker 1: floors and just not moving again, or climate control systems
Speaker 1: failing entirely. There were fears that airplanes would fall from
Speaker 1: the sky, and most of these fears were well beyond reality,
Speaker 1: but they circulated and they grew. This was the other
Speaker 1: edge of having access to the web. We're coming up
Speaker 1: on the end of this story, but before I get
Speaker 1: to that, let's take one last break. You know, by
Speaker 1: the late nineties, being online was fairly common. You know,
Speaker 1: the World Wide Web was the thing. We had not
Speaker 1: yet had the dot com crash, So the dot com
Speaker 1: world was starting to really take off and information could
Speaker 1: spread very quickly, and a lot of the information was
Speaker 1: about y two K. I still remember New Year's Eve.
Speaker 1: My spouse and I went to a club with some friends.
Speaker 1: It was a ridiculous end of the year slash potential
Speaker 1: end of the world celebration. Uh. They played Prince's nineteen
Speaker 1: nine way too many times. In fact, I would argue
Speaker 1: that although that song is amazing and I love it,
Speaker 1: it makes no sense to play it during because you're
Speaker 1: supposed to party like it's nine. Anyway, we counted down
Speaker 1: the year, I think three times because no one actually
Speaker 1: had access to an accurate time countdown. That seems pretty
Speaker 1: appropriate for y two K. And in the end, once
Speaker 1: everything was over, it was peaceful. Nothing catastrophic happened, and
Speaker 1: the next day we went home, and over the course
Speaker 1: of the following month we saw an outpouring of frustration
Speaker 1: and exasperation and ridicule. Rather than a sense of relief that,
Speaker 1: you know, the various computer programmers out there had spent
Speaker 1: countless hours creating stop gap solutions to get us through
Speaker 1: the transition, we saw people get upset about it, and
Speaker 1: the prevailing sense was that it was much ado about nothing.
Speaker 1: That those billions of dollar or is that we spent
Speaker 1: were spent on a non problem, and that seems pretty
Speaker 1: weird to me. I mean, the reason there weren't that
Speaker 1: many problems here in the United States is precisely because
Speaker 1: that sort of money had been spent on the solutions.
Speaker 1: The solutions prevented the problems from happening. That was the
Speaker 1: whole point. So I'm gonna use a dom analogy. Let's
Speaker 1: say I got a big, old farm and I happened
Speaker 1: to see reports that there's this unusual migration of deer
Speaker 1: moving across the region, and that within a couple of
Speaker 1: weeks they're gonna be where I am, and those deer
Speaker 1: could spell doom for my harvest. So I decided, I'm
Speaker 1: going to spend a large amount of money, and I'm
Speaker 1: gonna get a bunch of construction workers out there, and
Speaker 1: we're gonna put a deer proof wall around my farm.
Speaker 1: And so I spend all this money, we get the
Speaker 1: wall up, and then the day comes when the migration
Speaker 1: is supposed to be in my area, and I go
Speaker 1: outside and I look at my farm inside these walls,
Speaker 1: and there are no deer in the farm. I'm not
Speaker 1: gonna say, man, I wasted that money. I'm gonna say, hey,
Speaker 1: the wall worked well. Our y two K wall worked mostly.
Speaker 1: There were some scattered issues with systems that had not
Speaker 1: yet become Y two K compliant, but they were the
Speaker 1: exception rather than the rule, at least here in the
Speaker 1: United States. In other parts of the world there were more,
Speaker 1: you know, prevalent issues. For example, there were places in
Speaker 1: the UK that had trouble processing card transactions for the
Speaker 1: very reasons that I mentioned earlier in this podcast. Not
Speaker 1: only that, but we actually saw another outbreak of Y
Speaker 1: two K problems just last year in twenty This comes
Speaker 1: back to win doing so addressing Y two K problems,
Speaker 1: you you broadly had two major solutions. You could go
Speaker 1: in and actually reprogrammed stuff, but that was incredibly time
Speaker 1: consuming and expensive, and for certain legacy systems it was
Speaker 1: not practical because you still had those memory limitations in
Speaker 1: place for some of those legacy systems and you literally
Speaker 1: couldn't make those changes. Windowing was seen as a stop gap,
Speaker 1: the idea of being that, well, we're going to have
Speaker 1: to migrate stuff off of those legacy systems onto more
Speaker 1: modern systems that can have a four digit year, but
Speaker 1: in the meantime, let's use windowing. So again, windowing is
Speaker 1: about picking a two digit year and saying anything above
Speaker 1: this number should fall into the nineteen hundreds. Anything below
Speaker 1: this number is in the two thousand's. So again, if
Speaker 1: you pick fifty, as I mentioned earlier, sixty six would
Speaker 1: mean oh, well that's above fifty, so it's nineteen sixty six.
Speaker 1: But twenty two would be interpreted as, oh, that's below fifty,
Speaker 1: that means two thousand twenty two. That works for a while,
Speaker 1: and a lot of programmers who put in a windowing
Speaker 1: stop gap happened to choose twin t as the dividing line,
Speaker 1: perhaps because this put nineteen seventy in a prominent spot
Speaker 1: near the middle. Nineteen seventy also relates to a similar
Speaker 1: issue called UNIX time, which I will talk about at
Speaker 1: the very end of this episode. So when it was
Speaker 1: two thousand to two thousand nineteen, everything was fine because
Speaker 1: that windowing stop gap meant that computers were interpreting the
Speaker 1: year's zero zero to nineteen as being two thousand to
Speaker 1: two thousand nineteen. But then we hit twenty twenty, and
Speaker 1: now the computers were saying, oh, we're back in nineteen
Speaker 1: twenty now, because that was the number that was chosen
Speaker 1: by these programmers and the windowing stop gap and systems
Speaker 1: began to experience problems. This, by the way, really illustrates
Speaker 1: two big things. One is that windowing was really just
Speaker 1: man as a temporary patch. It was not a long
Speaker 1: term solution. The second is that we didn't learn a
Speaker 1: ding dang darn thing from the Y two K experience,
Speaker 1: because it's just the same gosh darn problem as why
Speaker 1: two K. All we did was punted down twenty years
Speaker 1: and then didn't do anything to prep prep for that,
Speaker 1: and so we had the problems again. Also, here's here's
Speaker 1: a fun bit. One of the pieces of software that
Speaker 1: was affected by this, fittingly enough, was w W E
Speaker 1: two K twenty, a wrestling video game, which had more
Speaker 1: than its share of problems. In fact, I could probably
Speaker 1: do a full episode about the incredible train wreck that
Speaker 1: was w W E two K twenty, but I will
Speaker 1: leave it here anyway, The company that made it, too
Speaker 1: K eventually issued a patch that fixed things for as
Speaker 1: far as that goes. Anyway, There are other problems, but
Speaker 1: again we'll leave that for a future episode. Now, I
Speaker 1: did mention just now that Unix time relates to nineteen seventy,
Speaker 1: so the Unix time stamp uses a thirty two bit integer,
Speaker 1: and it traces the origin of time to January one,
Speaker 1: nineteen seventy at zero hours, zero minutes, and zero seconds.
Speaker 1: That is when time began according to Unix. But because
Speaker 1: it's using a thirty two bit integer to mark the
Speaker 1: passage of time, and because it's marketing it all the
Speaker 1: way down to the second, that means there's a limit
Speaker 1: to how far this process of timekeeping can actually go.
Speaker 1: And we'll hit that limit on January nine, two thousand
Speaker 1: thirty eight, at oh three hours, fourteen minutes, oh seven seconds.
Speaker 1: At that point, we will have run out of space
Speaker 1: in that thirty two bit integer designation for time, and
Speaker 1: then all future time stamps will appear as if they
Speaker 1: are a negative number because of integer overflow, which will
Speaker 1: put the time back to nineteen o one. And you know,
Speaker 1: just in case you thought travel to the past was impossible,
Speaker 1: according to computers, it's only not possible at least for
Speaker 1: timekeeping purposes, and everything that is using a Unix based
Speaker 1: system will be treating the year as if it's nineteen
Speaker 1: o one at that point forward. So for Unix based systems,
Speaker 1: that means that we have an ongoing issue. There have
Speaker 1: been some proposed solutions, but they tend to be on
Speaker 1: a case by case basis, not too different from the
Speaker 1: early days of the Y two K problem and UH,
Speaker 1: if recent past is anything to go by, we can
Speaker 1: expect to see some stop gap solutions thrown in there
Speaker 1: that don't really fix anything, but they do push the
Speaker 1: problem further into the future because we're really good at that. UM.
Speaker 1: It's unfortunate because with a little work, well not a
Speaker 1: little work, with a lot of work, we can avoid
Speaker 1: the issue and not have to do triage every few
Speaker 1: decades to correct the issue we have of not creating
Speaker 1: a permanent solution UH and replacing a stop gap and
Speaker 1: instead our habit is to go with the stop gap
Speaker 1: approach because it's faster to implement, it's cheaper to implement,
Speaker 1: and we just collectively think that's a future me problem.
Speaker 1: And I'm as guilty of doing this kind of thing
Speaker 1: as anybody else's. In fact, I would argue I'm even
Speaker 1: more guilty of it. So I'm casting a lot of
Speaker 1: shade here, But someone that's got to hit on me.
Speaker 1: Even though I'm not a programmer, I've definitely fallen into
Speaker 1: that same sort of trap. But I hope this gives
Speaker 1: you a better appreciation of what the Y two K
Speaker 1: problem was and is, and why it's such a big
Speaker 1: deal and why like people were flipping out about it. Uh,
Speaker 1: And yeah, it can be kind of funny to see
Speaker 1: the extent to which some people were flipping out about
Speaker 1: it and worried that it was going to just bring
Speaker 1: about the end of civilization. But you can also understand
Speaker 1: for a society that had in recent memory ported over
Speaker 1: all of its most essential operations onto digital computer systems,
Speaker 1: how a failure in that system could be seen as
Speaker 1: being beaten times. I mean that parts understandable, right, especially
Speaker 1: if you don't have a deep knowledge of how computers work.
Speaker 1: To you, it could just be a mystery and it
Speaker 1: just means that all your stuff stops working the next day.
Speaker 1: That's a pretty terrifying prospect. As we know, it wasn't
Speaker 1: necessarily accurate, but that doesn't mean the Y two K
Speaker 1: problem was not a problem. It certainly was. I hope
Speaker 1: that you enjoyed this episode. Will be back later this
Speaker 1: week with some tech news and a new Smart Talks episode,
Speaker 1: and if you have any suggestions for topics I should
Speaker 1: cover in future episodes of tech Stuff, reach out to
Speaker 1: me on Twitter. The handle for the show is tech
Speaker 1: Stuff h s W and I'll talk to you again
Speaker 1: really soon. Tech Stuff is an I Heart Radio production.
Speaker 1: For more podcasts from My Heart Radio, visit the i
Speaker 1: Heart Radio app, Apple podcast wherever you listen to your
Speaker 1: favorite shows.