eli5: How did we solve the Y2K bug?

317 views

I understand what the general issue was for y2k. Computer systems that only recorded the last two digits of the year would reset to 01 Jan 1900 and cause issues for banks and other important records. My question is how did people fix the problem and test computers to make sure they were good? Was it a lot of manually typing in shell commands or could IT folks implement a patch with a floppy disk or some other removable media? How do you get a computer that was built to work with a certain date format to recognize dates in a new format?

In: 4

12 Answers

Anonymous 0 Comments

By going through and changing all the date formats to have four digit years.

When most of these programmes were written it was the 80s or even the 70s. It was a known issue, but the developers were just not expecting their systems to be used for that long.

They used a two digit year because every single byte was precious. Any memory saving measure was used.

By the time the year 2000 rolled around the memory available could be measured in gigabytes rather than kilobytes.

Anonymous 0 Comments

[removed]

Anonymous 0 Comments

different solutions for each system, I’m sure, but generally any system or application using two digits for date year, needed to be changed to four

Anonymous 0 Comments

The systems with the problem were big, customized, central computer systems so the IT staff would have done whatever was needed for that specific system. The programmers would have updated the programming and delivered a copy to IT by whatever system they were using for that computer. In the 1990s that was probably floppy disks, CDs or internet – that is, if the programming was a separate company. If the programmers were at the same company they might’ve been able to directly access the server and maybe the program was even written directly on the server. Programming discipline was a lot more lax back then.

Anonymous 0 Comments

It was tough. I had other programmer friends who were doing this.

The date field may have been two digits, say 25. This was done on a very old computer with little memory and storage. Since then the program has been moved to a more modern computer with more memory and storage, but the program was not altered.

So the program reads 25 and assumes 1925. The database storing the data also stores only 25. You have to do three things, change the program to use the date, change the database to store the date, and convert every number to a date.

It was a lot more complicated than this, but basically for all historical numbers we say “For every 25, make it 1925.” That’s easy with a script. But there are always outlier cases to worry about, like this held mortgage due dates so we want those 2025. so deep knowledge of the program and its data was necessary.

Anonymous 0 Comments

In general, the Y2K problem was mostly a software problem and less of a hardware problem. Even a computer system’s main software, the operating system, is loaded from disk. The specialized software that is part of the hardware, which we call firmware, doesn’t use years as much as ordinary software.

So, yes, patches for OSes and applications were shipped out from vendors to customers on CD-roms or floppy disks or more often over the internet. The Internet had already existed for more than 30 years at that point, it was just slower than today. Even in 2000, repetitive IT work was rarely done by typing in individual commands. If your vendor did not provide automated updates, the IT person would write a shell or batch script to perform them. If the new OS was too large to download over a slow internet for each of the machines you needed to update, you would download it once or get it off of a CD-ROM and put it on a local server for machines that needed an update to access over much faster local networks.

Anonymous 0 Comments

Software companies were very good about issuing patches. As a University IT support, I spent the last three months of the year making sure all of our software was up to date. We were closed for winter break, but I went in on January 1st to test our department server and workstations and didn’t have any problems.

While to many people it looked like the issue was overblown, in reality there was a lot of work behind the scenes to prevent major problems.

Anonymous 0 Comments

Y2K was simply not a problem for a lot of systems, but was easy to write news stories about. The year 2038 is the real problem. A lot of computer programs store times as:

“seconds since 1st Jan 1970”

This is a somewhat arbitrary starting point that works well for a lot of tasks since it allows you to store the time in seconds as a 32 bit integer which allows you to perform a lot of fast math on times. Computers don’t understand 21st Feb 2003 minus 4 days seven seconds natively, so your software needs to do a bunch of conversion. They do however understand 1.5 billion minus 2 million and can do that calculation blisteringly fast. With a system like this you only convert the output to something human readable when someone needs to view it, so it’s way more efficient. This system gives you all the dates between early 1901 (-2 billion seconds) to 2038 (+2 billion seconds).

So for many things which used standard 32 bit time, y2k wasn’t really a problem. You might have to fix the human interface input/output part of some programs, but most worked just fine. While potentially a decent amount of work, generally there was a software fix.

However the 2038 issue is potentially a much bigger one. This is the maximum time that a 32 bit epoch time system can hold, and any more seconds cause an overflow error and the time reverts back to 1901. That’s only 16 years away! For most modern electronics, they can use 64 bit time just fine which gives us almost 600 billion years worth of seconds, however there are **tonnes** of embedded microcontrollers in all sorts of systems that can’t move on from 32 bit time. Think avionics in aircraft (the B52 is like 70 years old, 30 year old aircraft are common), the sewage pump under your street, the xray machine at the hospital, your car, radio transmitters, missile control systems, telecommunication equipment, industrial machines in factories, ship navigation systems – the list goes on. This is the real Y2K bug.

Anonymous 0 Comments

It depends on how old the equipment being used was…. Only some seemed to require, as reported, updates filling up a mini boom of specialized IT professionals. The majority of it went off without a single hitch needing updates because the technology accounted for the changing dates properly which probably has something to do with a proper connection to the time clock all technology gets synced with

Anonymous 0 Comments

The affected systems were either patched with a software update or entirely replaced.

Yes Y2K was a problem in a lot of systems, but the scope of how many systems were affected was badly overblown by the media.

>My question is how did people fix the problem and test computers to make sure they were good?

Companies that make the software have demo labs for testing with fake data. They just set the clocks to a few minutes before midnight on Dec 31 1999 and waited to see if anything broke.

>Was it a lot of manually typing in shell commands or could IT folks implement a patch with a floppy disk or some other removable media?

Yes and No

You would use whatever patching process was used for that particular piece of software. Yes sometimes back then it would have been a floppy disk.

The development side of things was more complicated. Thousands of lines of computer code potentially had to be updated to reflect having those extra digits on the year. Now factor in that a lot of that software was by its nature very old and often written in program languages that weren’t really in use anymore and you start to understand why this was a problem.

> How do you get a computer that was built to work with a certain date format to recognize dates in a new format?

You don’t

If it was a hardware problem the hardware likely had to be replaced. Software meanwhile could be updated.

But for equipment that wasn’t Y2K compliant we’re talking about hardware that by this point was probably already 15-20 years old on average by 1999.

Developers had known about this bug for a long time and had fixed it a long time before.

Many IT department just used the panic of Y2K as an excuse to get the budget to replace their aging hardware.