July 26, 2021 • 52 mins
In the late 90s, the Y2K bug was a big news item. People worried that everything from toasters to airplanes would fail as computer systems mishandled the change from 1999 to 2000. But what was really going on, and why did Y2K come back last year?
Learn more about your ad-choices at https://www.iheartpodcastnetwork.com
See omnystudio.com/listener for privacy information.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Welcome to Tech Stuff, a production from I Heart Radio.
Hey there, and welcome to tech Stuff. I'm your host,
Jonathan Strickland. I'm an executive producer with I Heart Radio,
and I love all things tech. And if you are
in your early twenties or you are younger than that,
(00:26):
you missed out on a pretty big deal in tech.
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
(00:48):
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
(01:11):
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
(01:33):
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
(01:55):
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
(02:16):
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
(02:39):
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,
(03:02):
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
(03:23):
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,
(03:44):
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,
(04:04):
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
(04:26):
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,
(04:46):
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
(05:10):
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.
(05:33):
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
(05:53):
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
(06:15):
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
(06:38):
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
(06:59):
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,
(07:20):
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
(07:40):
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,
(08:02):
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
(08:24):
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
(08:49):
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,
(09:09):
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.
(09:30):
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
(09:52):
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
(10:15):
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
(10:35):
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
(10:55):
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
(11:19):
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
(11:42):
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
(12:04):
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
(12:26):
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.
(12:50):
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
(13:11):
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
(13:33):
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,
(13:54):
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
(14:15):
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
(14:35):
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
(14:58):
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
(15:19):
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
(15:39):
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
(15:59):
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,
(16:20):
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
(16:42):
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.
(17:03):
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
(17:23):
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
(17:43):
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
(18:06):
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
(18:30):
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.
(18:51):
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
(19:14):
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
(19:35):
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
(19:56):
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
(20:18):
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,
(20:40):
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
(21:02):
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,
(21:26):
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
(21:48):
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
(22:10):
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
(22:33):
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.
(22:54):
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
(23:15):
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
(23:38):
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
(23:58):
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
(24:20):
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
(24:42):
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.
(25:05):
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
(25:27):
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,
(25:47):
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
(26:11):
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
(26:34):
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
(26:55):
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
(27:17):
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.
(27:41):
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
(28:03):
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
(28:24):
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
(28:47):
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
(29:10):
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
(29:34):
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
(30:03):
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,
(30:26):
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
(30:47):
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
(31:08):
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.
(31:30):
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.
(31:50):
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
(32:10):
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
(32:31):
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
(32:53):
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.
(33:14):
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
(33:35):
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
(33:58):
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
(34:19):
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
(34:41):
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
(35:04):
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
(35:27):
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
(35:48):
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
(36:09):
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.
(36:32):
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
(36:53):
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
(37:16):
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
(37:36):
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
(37:58):
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,
(38:23):
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
(38:45):
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
(39:07):
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
(39:27):
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
(39:48):
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
(40:09):
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
(40:29):
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
(40:51):
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
(41:15):
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
(41:36):
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
(41:58):
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
(42:20):
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,
(42:44):
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
(43:05):
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
(43:26):
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.
(43:47):
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.
(44:09):
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
(44:29):
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
(44:51):
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,
(45:14):
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
(45:38):
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,
(46:02):
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
(46:24):
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
(46:47):
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
(47:09):
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
(47:32):
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,
(47:54):
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
(48:15):
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
(48:37):
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
(48:58):
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
(49:20):
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
(49:42):
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,
(50:06):
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
(50:29):
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
(50:53):
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.
(51:14):
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
(51:36):
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
(51:58):
Heart Radio app, Apple podcast wherever you listen to your
favorite shows.
Welcome to Tech Stuff, a production from I Heart Radio.
Hey there, and welcome to tech Stuff. I'm your host,
Jonathan Strickland. I'm an executive producer with I Heart Radio,
and I love all things tech. And if you are
in your early twenties or you are younger than that,
(00:26):
you missed out on a pretty big deal in tech.
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
(00:48):
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
(01:11):
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
(01:33):
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
(01:55):
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
(02:16):
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
(02:39):
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,
(03:02):
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
(03:23):
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,
(03:44):
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,
(04:04):
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
(04:26):
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,
(04:46):
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
(05:10):
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.
(05:33):
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
(05:53):
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
(06:15):
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
(06:38):
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
(06:59):
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,
(07:20):
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
(07:40):
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,
(08:02):
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
(08:24):
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
(08:49):
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,
(09:09):
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.
(09:30):
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
(09:52):
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
(10:15):
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
(10:35):
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
(10:55):
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
(11:19):
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
(11:42):
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
(12:04):
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
(12:26):
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.
(12:50):
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
(13:11):
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
(13:33):
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,
(13:54):
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
(14:15):
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
(14:35):
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
(14:58):
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
(15:19):
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
(15:39):
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
(15:59):
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,
(16:20):
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
(16:42):
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.
(17:03):
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
(17:23):
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
(17:43):
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
(18:06):
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
(18:30):
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.
(18:51):
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
(19:14):
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
(19:35):
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
(19:56):
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
(20:18):
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,
(20:40):
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
(21:02):
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,
(21:26):
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
(21:48):
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
(22:10):
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
(22:33):
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.
(22:54):
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
(23:15):
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
(23:38):
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
(23:58):
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
(24:20):
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
(24:42):
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.
(25:05):
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
(25:27):
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,
(25:47):
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
(26:11):
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
(26:34):
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
(26:55):
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
(27:17):
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.
(27:41):
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
(28:03):
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
(28:24):
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
(28:47):
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
(29:10):
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
(29:34):
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
(30:03):
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,
(30:26):
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
(30:47):
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
(31:08):
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.
(31:30):
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.
(31:50):
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
(32:10):
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
(32:31):
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
(32:53):
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.
(33:14):
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
(33:35):
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
(33:58):
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
(34:19):
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
(34:41):
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
(35:04):
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
(35:27):
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
(35:48):
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
(36:09):
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.
(36:32):
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
(36:53):
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
(37:16):
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
(37:36):
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
(37:58):
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,
(38:23):
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
(38:45):
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
(39:07):
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
(39:27):
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
(39:48):
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
(40:09):
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
(40:29):
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
(40:51):
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
(41:15):
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
(41:36):
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
(41:58):
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
(42:20):
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,
(42:44):
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
(43:05):
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
(43:26):
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.
(43:47):
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.
(44:09):
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
(44:29):
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
(44:51):
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,
(45:14):
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
(45:38):
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,
(46:02):
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
(46:24):
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
(46:47):
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
(47:09):
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
(47:32):
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,
(47:54):
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
(48:15):
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
(48:37):
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
(48:58):
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
(49:20):
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
(49:42):
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,
(50:06):
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
(50:29):
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
(50:53):
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.
(51:14):
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
(51:36):
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
(51:58):
Heart Radio app, Apple podcast wherever you listen to your
favorite shows.
TechStuff News
Hosts And Creators
Oz Woloshyn
Karah Preiss
Popular Podcasts
United States of Kennedy
United States of Kennedy is a podcast about our cultural fascination with the Kennedy dynasty. Every week, hosts Lyra Smith and George Civeris go into one aspect of the Kennedy story.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.