Fixed crashes
In the world of information technology, there is the concept of the “Unix Era”, a time reference system that began at 00:00:00 UTC on January 1, 1970. This decision was made due to the high cost of computer memory and storage. Media of the 1960s. Programmers needed to save on everything, including storing time data. The number of seconds that passed after this point became the basis of many operating systems (such as Unix and its derivatives). These simplified calculations allow easy calculation of time intervals. However, they later led to problems.
One of the first signs of a possible disruption was a phenomenon called the “Year 2000 problem” (or Y2K). In the middle of the last century, many programs used the last two digits of the year to store the date. This was a perfectly rational solution in the face of memory constraints. However, by the year 2000, it became clear that programs could not distinguish between 1900 and 2000. All of this could lead to failures in important systems such as banking, aviation, and medicine.
Predictions of the possible consequences of Y2K sounded catastrophic: from power plant shutdowns to aviation failures. Governments around the world began preparing, forming special commissions to find solutions to the possible problems.
“Many of these fears turned out to be exaggerated. Programmers, especially COBOL (Common Business Oriented Language – one of the oldest programming languages), quickly adapted old programs by increasing the bit depth of date fields and including centuries. As a result, the “digital apocalypse” was averted. The situation showed how important it is to respond to such challenges in a timely manner,” Daniil Efimov, director of the NUST MISIS Center for Technology Competitions and Olympiads, told socialbites.ca.
New millennium, new problems
A similar problem emerged in 2010: “Y2K+10.”
“There was confusion between the binary-coded decimal (BCD) and hexadecimal encoding of numbers. Both encode the digits zero through nine as 0x0–0x9. But the number 10 is different: BCD is 0x10, hexadecimal encoding is 0x0A, and 0x10 represents the number 16. Some systems mistakenly recognized 2010 and displayed it as 2016,” explains Daniil Efimov.
As a result, some SMS messages arrived with the wrong date: 2016 was indicated instead of 2010. The outages hit German banks the hardest, where chips on 20 million cards were now unidentifiable. There were two solutions to the problem with the cards: reconfigure terminals and ATMs nationwide or issue new cards with the correct chips. The latter was too resource-intensive, so we decided to update the software on tens of thousands of terminals and ATMs. It took several weeks.
But according to programmers, there is another problem that could arise in 2038.
“The 2038 problem affects 32-bit processors that have been able to store time values up to a certain limit, such as 2147483647 seconds, since the beginning of the Unix Era. This limit will be reached on 19 January 2038 03:14:07 (UTC).and then systems using 32-bit timers will go back to the beginning and start displaying negative values,” Efimov says.
This can cause problems with ATMs, medical equipment, navigation systems, and other critical devices.
But programmers have already figured out how to prevent a failure in 2038. The transition to 64-bit systems allows you to store large time values, up to 9223372036854775807 seconds. This is equivalent to more than 292 billion years.
Doomsday and Leap Years
Another future problem involves what are called “days 32,768 and 65,536.” Programs that store dates as the number of days since a certain time (e.g., January 1, 1900) are susceptible to overflow when 16-bit values are used.
“In systems with 16-bit signed numbers (storing a negative or positive number), overflow occurs after 32,768 days (2 to the 15th power, since the first digit is used to store the sign), resulting in negative values. For example, on September 18, 1989, negative day values caused errors, which caused crashes in some systems. Similarly, 16-bit unsigned variables (i.e. 2 to the 16th power, since the first sign is also used to store the number) can overflow after 65,536 days, resulting in zero values,” explains Daniil Efimov.
For programs counting days from January 1, 1900, this will occur on June 6, 2079, which can cause problems for systems that use this method of time storage. This is also a possible “digital doomsday” day.
There is another problem with the time calculation. Contrary to expectations, it could happen in the year 2100, which will not be a leap year.
“According to calendar rules, years that are divisible by 100 are not leap years unless they are divisible by 400. Many software systems that use simplified algorithms to calculate leap years may calculate the date incorrectly by adding February 29, 2100, instead of March 1,” Efimov says.
This can cause outages to operating systems, calendars, financial systems, and other services that rely on accurate time tracking.
Invisible Front
Software and hardware become more complex every year as new technologies require integration with existing systems. Humanity continues to use systems created decades ago, and their developers are often no longer involved in their support and modernization.
So engineers and programmers not only have to keep these legacy systems running, but also solve everyday problems that were not thought of when they were first created or could not be solved due to the technological limitations of the time.
One of these problems is timing, which is what all automated systems in the world depend on for accuracy. But so far, programmers have managed to find ways to maintain the stability and performance of all these systems.
What are you thinking?
Source: Gazeta
Jackson Ruhl is a tech and sci-fi expert, who writes for “Social Bites”. He brings his readers the latest news and developments from the world of technology and science fiction.