The basic problem behind both is a lack of forethought.
Back in the pre-2000s, especially in the 70s and early 80s, computers had very little RAM. Therefore, rather than store all four digits of the year - say ā1999ā, many computers and programs only kept the last two digits - ā99ā. Computers also had very little storage, so the date was often stored that way as well.
The obvious problem with this is once a new century begins, you roll back to ā00ā, which a program could potentially interpret as suddenly being 100 years in the past. There was a lot of hysteria surrounding Y2K (people thought things like banking software would spontaneously combust and society would collapse) but most important programs and databases were updated in time for Y2K to not affect them, and otherwise mostly only minor bugs really occurred.
Fast forward to today: most computers store time using a method called āUNIX timeā. Basically, time is stored as the number of seconds that have elapsed since January 1st, 1970. The problem is UNIX time is stored in a signed 32 bit integer. A signed 32 bit integer can store any number between -2,147,483,648 and 2,147,483,647. It just happens that 2,147,483,647 seconds from January 1st, 1970 lands somewhere around 2038. When a variable overflows the maximum possible number, it rolls back to the minimum possible number. This may cause computers and software to believe the date is somewhere around 1901.
The good news is that UNIX time can be stored in any arbitrary number of bits. We can simply move to 64 bits and be good until the heat death of the universe.
The bad news is fixing legacy systems (from the viewpoint of 2038, so fixing everything that currently exists and is going to exist in the next couple decades) is going to be a lot more complex than fixing the Y2K bug.
Since essentially all platforms store UNIX time in 32 bits (yes, even our modern 64 bit systems), nearly all code that uses the UNIX time (or gets the date at all, since the library that retrieves the date is almost certain to use UNIX time) assumes the time is stored in a signed 32 bit integer. Making any sort of change to that means breaking compatibility with a lot of code. As in, all the code that exists today, and all the code that will continue to be made until we fix the problem. Thereās going to be more than half a century of code to fix by the time 2038 rolls around.
Past that, the internet is a much bigger worry now than it was in 1999. Much of the internet relies on certificates for security that are only valid in a certain date range, of which 1901 is certainly included in none. Try setting your computerās clock a few years in the past then try accessing any website that uses https. If the 2038 problem isnāt fixed in time, essentially all services that rely on the internet will no longer be accessible. Thatās a pretty massive problem that really could cause the collapse of society if it isnāt fixed.
Thereās a multitude of other areas where solving the 2038 problem is non-trivial as well. In addition to that, nobody really seems to be worried about this problem yet. Expect to see mass panic a few years before 2038 comes as everyone suddenly realizes āoh shit we need to fix this nowā.
dailybridgerton
titsay
gummygunk
yousharknotpass
prguitarman
areudirty
snowghoul
romaincrisis
