Year 2038 problem

from Wikipedia, the free encyclopedia

Template: future / in 5 years

Exemplary representation of the year 2038 problem (binary = binary, decimal = decimal, date = date). The Unix time is exceeded in this representation.

The year 2038 problem of IT systems ( numeronym : Y2K38 ) could lead to software failures in 2038. This problem is limited to IT systems that use Unix time and define it time_tas a signed 32-bit integer .

background

The Unix time counts since January 1, 1970 elapsed time in seconds. On Tuesday, January 19, 2038 at 3:14:07 a.m. UTC , the number of seconds that have passed will exceed the capacity of a signed 32-bit integer (maximum value 2,147,483,647, 2 31 −1). According to convention, the most significant bit ( MSB ) is used to distinguish positive and negative numbers ( sign in two's complement ) so that the count jumps into the negative range if the value 2,147,483,647 (binary 01111111 11111111 11111111 11111111) is exceeded (e.g. B. −2,147,483,648 binary 10000000 00000000 00000000 00000000). If the conversion from Unix time to date and time is insufficiently implemented, this unintentionally results in the value being interpreted as 8:45:52 pm on Friday, December 13th, 1901 UTC. This problem is known as counter overflow in software development .

Without countermeasures, the economic effects could be damaging, especially since Unix systems are standard equipment in addition to mainframes in the banking and insurance sector . In addition to the Unix servers, many embedded systems work with Unix-like operating systems, the operating time of which is often many times that of desktop and server systems (e.g. routers and electronic measuring devices ). An adaptation or modernization of corresponding computer systems in companies and institutions that is at least delayed, but necessary in the long term, could reduce the probability of failure.

An example of typical year 2038 errors are transactions whose validity is derived from the time stamp of the result field. If the result is not younger than the original data, a valid result is still waited for or the transaction is automatically restarted at some point. On the key date of the year 2038 problem, however, all results will have the alleged timestamp December 1901 and are therefore always older than the input data. Waiting programs can easily get into endless loops , which the end user could see as "hanging" applications.

remedy

The Unix time counter is expected to be implemented as a 64-bit counter in most systems well before the year 2038 ; in OpenBSD this has already been done. This has to do with the fact that the Unix-typical C definition refers to the base type " long ". It has already become established in the Unix environment that when the 32-bit to 64-bit architectures transition from this very basic type to 64-bit (technically: conversion from ILP32 to LP64 model), so that time stamps are at least system-based as 64-bit time_tto be delivered. The 64-bit conversion means that the POSIX time stamp can work reliably for 292 billion years without an overflow occurring.

Nevertheless, a changeover to new 64-bit processor architectures ( AMD64 / EM64T , Itanium / IA-64 , IBM Power 5 , UltraSPARC , PA-RISC , MIPS ) is not enough here: it simplifies the system-side adaptation, but it does the thinning and re-translation of all programs with rigid 32-bit formatting is not superfluous. Not all programs are already 64-bit-compatible, and it is easily possible that 64-bit time stamps supplied by the system are incorrectly processed as 32-bit values ​​and thus only the lower-order 32 bits are queried, which are then detached again on January 19, 2038 assume the value −2 31 = December 13, 1901.

Another remedy is to convert the programs from the Unix time counter to a new time base ; Counting milliseconds or microseconds with 64-bit counters (which do not necessarily require a 64-bit architecture) is already widespread, especially in embedded systems with real-time requirements of this magnitude. Newer time APIs always use greater precision and range than Unix time, for example Java System.currentTimeMillis (64-bit milliseconds since January 1, 1970; sufficient for 292 billion years) and .NET System.DateTime.Now.Ticks (64-bit 10ths of a microsecond since January 1, 0001 ; sufficient for 29227 years). The database-supported transactions often use TIMESTAMPvalues ​​that are defined in the database standard SQL 92 with an accuracy in microseconds (also accessible in ODBC / JDBC ) and their representation in databases usually takes place as a distance to the day counter (SQL DATE), whereby the day counter is also in 32 bit has a larger range (the underlying epoch of the day counter, however, is very different). If these data types for time stamps are used consistently in the program, the restrictions of the Unix time counter are eliminated.

Another remedy is to save the time stamp as a character string, as provided for in ISO 8601 , as a YYYYMMDDHHMMSS time stamp e.g. B. "20140823142216". These are spared from year overflow problems at least until December 31, 9999 11:59:59 PM, unless the internal operations (e.g. to calculate the difference between two time stamps) convert them into a problematic binary format.

Related year 2036 problem

Closely related to the year 2038 problem is the year 2036 (numeronym: Y2K36 ). On February 7, 2036 at 6:28:16 a.m. UTC, the counter of the time synchronization protocol NTP ( Network Time Protocol ) originally developed for UNIX overflows . In modern implementations this problem has been resolved (see RFC 5905 ), but a large number of devices - especially embedded systems - still work according to the old RFC 868 standard .

Here, too, the background is that the time is transmitted as a 32-bit number in seconds, but with the start time January 1, 1900 and unsigned, 00:00:00 UTC. If the systems are implemented very properly, there will be no (major) problem during the calculation, since the time synchronization should work according to a difference method.

However, invalid values ​​- depending on the implementation - can also occur when working in both the NTP and UNIX format: This applies in particular to the growing number of embedded systems in the context of the Internet of Things , where the system time is determined due to the lack of a battery-supported real-time clock each time it is started, the time server must initially be in NTP format, but this is then converted into the usual Unix time for further representation (by subtracting the time difference). If the time after (not infrequently) failed connection attempts is specified here with 0, and accordingly with 1900-01-01 00:00:00 UTC (cannot be displayed in Unix time), unsecured conversions to UNIX format would become invalid and (if signed) also lead to a negative value, with comparable effects on the system and its behavior.

See also

literature

  • OpenBSD 5.5 with 64-bit system time . In: c't 2014, issue 12, p. 50.

Individual evidence

  1. ^ Seconds Since The Epoch. Retrieved December 16, 2010 .
  2. ↑ https://www.heise.de/ct/artikel/Prozessorgefluester-285204.html
  3. ↑ Linux Standard Base Core Specification 4.0. Retrieved December 16, 2010 .
  4. ↑ man pages section 3: Library Interfaces and Headers. (No longer available online.) Formerly in the original ; accessed on December 16, 2010 (English).  ( Page no longer available , search in web archives )  Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.@1@ 2Template: Dead Link / docs.sun.com  
  5. ↑ HP-UX Reference Volume 5 of 5. types (5). Retrieved December 16, 2010 .
  6. ↑ See English Wikipedia NTP Timestamps
  7. ^ NTP Timescale and Leap Seconds. Retrieved November 30, 2015 .