To me, one of the most fascinating tech phenomena was Y2K, also known as the Millenium Bug or the Year 2000 Bug. It tells the tale of unseen heroes working round the clock to fix the most vital parts of tech infrastructure, all for the public to call it a hoax. It's a tale of bravery, efficiency and public outcry, all due to code written over 40-60 years back.
So, why am I talking about this? Well, something similar seems to be coming up. I highly doubt it'll be as severe as Y2K, but it's a similar problem; Y2K38. On 03:14:07 UTC on 19 January 2038, systems still using 32-bit timing will stop functioning properly. The reason for this is actually quite straightforward. Imagine you have an abacus.
Now, let's say you get to 999,999,999.99999, which is the maximum value that your abacus can handle. How would you add another 0.00001? Well, to humans, you can't. It's literally impossible. However, with computers, what ends up happening is that they wrap around. To a negative value. See what's going on? 03:14:07 UTC on 19 January 2038 just so happens to be 2^31 seconds away from 00:00:00 UTC on 1st January 1970. This date is known as the Unix epoch and it's what most modern computers use to count time. When the variable rolls back to -(2^31) or 20:45:52 UTC on 13 December 1901. 32-bit variables can only store between 2^31 and -(2^31) numbers.
However, not all hope is lost. The vast majority of systems today are using 64-bit time variables, which has a final date of 23:34:33 UTC 21st July 2554 (2^64). If you're a consumer, you have nothing to worry about. Also, 2038 is a bit far into the future, so solutions can be hammered out for large enterprises.
So, that was my look at one of the most intriguing problems of the late 90s and early 2000s, as well as its new counterpart. I hope you enjoyed reading this, and goodbye!
Bình luận