I understand the number would have still overflowed *eventually* but why was it specifically new years 2000 that would have broken it when binary numbers don’t tend to align very well with decimal numbers?
EDIT: A lot of you are simply answering by explaining what the Y2K bug is. I am aware of what it is, I am wondering specifically why the number ’99 (`01100011` in binary) going to 100 (`01100100` in binary) would actually cause any problems since all the math would be done in binary, and decimal would only be used for the display.
EXIT: Thanks for all your replies, I got some good answers, and a lot of unrelated ones (especially that one guy with the illegible comment about politics). Shutting off notifications, peace ✌
In: 478
Because at some time in the past they were stored in 8-bit binary memory locations giving only 0-255, so they used 00-99 for the year.
Calculations that used those year-indications would give weird results, for instance in duration calculation. (Year now minus year back then would give negative time after year 99)
Later they used 16/32/64 bit systems but they would not change the software to use 00-99 and then came 2000…
2038 is the next one!
Dates were represented as a 2 digit year in order to save memory and disk space in early days when there was only so much to work with. Also, many systems were developed without a thought that they would still be in use in the year 2000. So after 1/1/2000, if you did a date calculation such as 1/1/00-1/1/80 the system would return a negative number which caused issues.
Because at some time in the past they were stored in 8-bit binary memory locations giving only 0-255, so they used 00-99 for the year.
Calculations that used those year-indications would give weird results, for instance in duration calculation. (Year now minus year back then would give negative time after year 99)
Later they used 16/32/64 bit systems but they would not change the software to use 00-99 and then came 2000…
2038 is the next one!
The problem was not the modern binary representation or the technology in the 1990s in general. When computers began to be usable for reallife applications, every byte of memory was costly.
Software Engineers of the 1970s began to save as much resources as possible, and that included printing dates to paper for humans to read. One obvious pattern to save memory was to not have a second copy of identical dates (one that is human readable, and one that is binary), but to have number (and date) arithmetic operating directly on its human readable, decimal representation. It was a shortcut but it worked.
They were fully aware this solution would not work in the year >2000, but In the 70s no one expected their technology to still be around 30 years later.
But then of course working code gets rarely touched, to the contrary actually working code gets copied a lot. Such that old code easily ends up in banking backends, elevators, and what-not microprocessors.
Dates were represented as a 2 digit year in order to save memory and disk space in early days when there was only so much to work with. Also, many systems were developed without a thought that they would still be in use in the year 2000. So after 1/1/2000, if you did a date calculation such as 1/1/00-1/1/80 the system would return a negative number which caused issues.
One byte stores. -128 to 127 (or 0 to 255).
That would only allow you to store the last two digits, eg, 1999 would be stored as 99, 2000 would be stored as 00.
The code could work in different ways. So the time difference between this year and last year would be 2023-2022 = 1 or 23 – 22 = 1.
But the problem is
2000-1999=1 or 00 – 99 = -99
But this is just a possibility. In my company, out of over a million lines of code, there were no problems.
But we still had to check.
Latest Answers