I understand the issue itself and when I read the Wikipedia it has list of solutions at the bottom that numerous different programing languages and programs have implemented. Are these solutions widespread? Is the issue itself sort of overblown with how technology exists today?
In: 0
> Are these solutions widespread?
They are ’bout to be, and there will be many coffee mugs emptied and bank accounts filled in the process.
> Is the issue itself sort of overblown with how technology exists today?
Nah, as always the old crap that’s designed to be tossed out and remade in 10 years tends to be the stuff that survives for 50. Plenty of important stuff still running Windows XP (or on an [IBM AS/400](https://wikipedia.org/wiki/AS/400)) that will need to be dusted off and patched.
And, once again as usual, programmers fix the issue on time and nothing happens, people will laugh about how it was overblown and nothing needed to be done after all.
The main way we will fix this is by moving by 32 bit processors to 64 bit processors. On the consumer end, we’ve basically done this. The 32 bit processors are mostly going to be older computers, and we suspect that by 2038, these will have been replaced as people decide to upgrade to better computers.
It may be a problem for more industrial applications where a computer may be used as a part of a device meant to last decades. Those will require a bit more work to fix. They will either need to be replaced or we’ll need to write software that can handle larger dates. It’s also possible that they won’t need any changes, even if their processor is 32 bit because it’s being used by some application that isn’t concerned with the date. We will want to test those systems to make sure that they could keep functioning after 2038.
The problem is going to be all the decades old embedded systems that are out there. For plenty I expect we’ve lost everything required to even update the firmware. Vulnerable systems are all over the place. Issue systems are things like:
* Flight computers on aircraft
* Control systems for power stations
* A sewage pump under your street
* Medical imaging equipment
* Military equipment
* Petrochemical equipment
* Heavy machinery
* Hydroelectric dams
* Scientific equivalent
Lots of these things have extremely long service and can easily span 50 years. For a lot of them you can work around the date issue, just set the date back to the 70’s and carry on. Often, with these old things, they’re so antiquated that we can’t safely interface them with modern computer systems anyway – so we’ve got pretty good at working around their limitations. For the others, I expect there will be a lot of surprises, and a lot of equipment suddenly obsoleted since its impractical to fix. There will probably be a few high profile incidents.
Computers count time starting at 0 and counting up every second until it reaches 2^31 -1 seconds.
What we agreed on as the starting point was January 1st, 1970 at 0:00 UTC. That’s why computers default to this time when there is no value (or December 31st, 1969 if you live in the Western Hemisphere)
January 19th, 2038, at 3:14:07 UTC is exactly 2^31 -1 seconds from January 1st, 1970, at 0:00 UTC
Now, why is 2^31 -1 the magic number? That’s because the way computers store the current time is as a 32-bit integer. More modern systems already in use use a 64-bit integer and can run until 2^63 seconds, which is about 292 billion years.
I’ll use a 4-bit example to explain what happens during the overflow.
0 is 0000
1 is 0001
2 is 0010
3 is 0011
4 is 0100
5 is 0101
6 is 0110
7 is 0111 (this is 2^3 -1)
But then we get to 1000, which is -8
1001 is -7
1010 is -6
And so on until 1111 is -1
That first number is called the sign bit because if it’s 0, the number is positive (or 0), and if it is 1, the number is negative.
So when we got to 7 (2^3 -1) the next number it tries to go to is 8, but 8 doesn’t exist, so it thinks the number is -8 and then starts counting up from there.
When the clocks do this, they will get to January 19th, 2038, they will then overflow and go back 2^31 seconds before January 1st, 1970, which is some time in December 1901.
The very same issue happened with YouTube view count for Gagnam Style reached 2^31. It was the first video to do so, and YouTube didn’t catch it in time, so briefly the view count for the video was in the -2 billions (continuing to count up, towards 0) until YouTube switched to storing views as a 64-bit integer.
The easiest solution is to switch time to a 64-bit integers, but people are also suggesting other solutions, including a 64-bit integer counting milliseconds, and it will only last 292 million years rather than billion.
This is exactly what people thought would happen with the Y2K bug (serious people, not the doomsday paranoia) and some systems were susceptible to that, but the 2038 problem is much more wide spread, but we’re also getting a jump on it much sooner.
Yup the problem is pretty much already solved.
The issue only really exists on Unix based systems or any software that uses Epoch time. The solution is very simple which is why it can be widespread quite easily. For software that uses Epoch time it the programmers maintaining software simply need to change a 32 bit integer to a 64 bit integer which sounds simple it may not be but it’s probably one of the easier changes to make. For the operating system the counter also needs to be changed to a 64 bit integer, for 32 bit systems the need to emulate 64 bit add operations. When the counter low half of the counter overflows the overflow bit is set if the overflow bit is set I add one to my higher half of the counter.
Latest Answers