What is Year 2000 problem (or Y2K bug)

Risks and potential damage

In the late nineties, as the problem became popular, various theories began to appear around it. People imagined a lot of stuff like the fall of the world finance system, or even worse nuclear apocalypse because of errors in military nuclear software. These talks raised quite a panic in society and people bought and stockpiled weapons, medicine and food, preparing for worst-case scenarios.

Panic around the problem

Y2K bug potentially may cause unpredictable errors and unstables in programs which worked with dates. Since at this time a lot of processes in important fields like military, government, finance and medicine were related on computer’s - people were seriously afraid that it could cause real problems up to the apocalypse.

Solving the problem

First person who spoke publicly about the issue was Bob Bemer in 1958. Then different people in different fields noticed the issue and even put effort into fixing it, but most of the work was done only in the last 3 years before 2000. Private companies and governments worldwide participate in fixing errors and minimize potential damage. Around 500 billions of dollars were spent on fixing this issue and consequences of it. To prevent this issue it was recommended to use unix time format that stores dates as number of seconds since 1 january 1970.

How people fixed Y2K bug in old systems?

But for fixing old systems that already stored years with 2 digits were used several different approaches:

• Adding 2 more digits to date - this method requires a lot of work, testing and additional storage.
• Program use century only when it’s needed - this was a lot easier and mostly required only a little patch for code.
• Converting dates to integers instead of storing them as day, month and year.
• In the old database, the old date which was stored as 2 digits for day, 2 for month and 2 for year can be converted into 3 digits for year (starts with 0 for 20th century and starts with 1 for 21 century) and 3 digits for day of year. It allows keeping the size of the database without changes.

Real impact of problem

In conclusion, damage was minimal even in countries that didn’t invest into fixing the problem. A lot of errors were documented, but all of them were far from critical. Mostly it was issues with ticket machines or terminals, but all cases were short and quickly fixed. So in reality Y2K wasn’t that bad and in most cases it was more about panic than about real danger.

Profit for industry

The Y2K bug had not only bad consequences, programmers worldwide were facing problem and cooperating to solve it. At this time the best practices for software development started rising. People wanted to gather knowledge together and help other developers build better systems and avoid global errors like this. Also the process of fixing this bug showed how important are software testing and code review and this practices become standart after that.

Similar problems

The Y2K issue is the most well-known, but not the only similar problem.

Year 2038 problem

One of the most popular formats of representing dates now is unix time - it stores the number of seconds from 1 january 1970 on 32 bits. And the problem here is the max number that you can store in 32 bits is 2³¹ - 1 or 2,147,483,647. And this is 03:14:07 19 January 2038. After that value, the system will try to increase the counter - it will cause integer overflow which as result will change the number to -2³¹ which represents 1901 year.

Y10K problem

Now for storing a year using only 4 digits, but when the year 10000 will come it won’t be enough anymore. This problem is far from now, but some people already noticed it, for example in Microsoft excel.