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
Since no one has mentioned this, I think you’re mixing the y2k bug with the year 2038 problem. In computers that use UNIX time to keep track of time, they count in binary in the form of a 32 bit digit, which means a sequence of 32 1’s and 0’s used to represent the time.
The time is counted from time 0 in binary, represented by 32 0’s in this 32 bit number. Time 0 represents January 1st, 1970, and to get the current time and date you can take the current value and plug it into a formula to get the current date as the elapsed time since then.
The problem is, eventually as you count up, the 32 bit number won’t be able to go any higher since it’ll go to all 1’s for the largest value. That date corresponds with January 19th, 2038. At that point it’ll either stop or roll back over to January 1st, 1970, messing up the time and potentially many program executions.
While this may be an issue for older systems, many computers now use 64 bit numbers. To count to the final value would take about 292 billion years, which is about 21 times longer than the estimated age of the universe.
Latest Answers