Year 2038 problem

Template: Future / In 5 years

The year -2038 problem of computer systems ( Numeronym: Y2K38 ) could lead to software failures in 2038. This problem is limited to computer systems that use the Unix time and time_t defined as a signed 32- bit integer.

Background

The Unix time counts the time elapsed since January 1, 1970 Time in seconds. On January 19, 2038 at 03:14:08 UTC clock, the number of seconds elapsed will exceed the capacity of a signed 32 - bit integer (up to 2.147.483.647 ). The most significant bit ( MSB) is by convention used to distinguish positive and negative numbers ( signed two's complement ), so the count jumps for any excess of the value of 2,147,483,647 (binary 01111111111111111111111111111111 ) in the negative range (eg - 2,147,483,648 binary 10000000000000000000000000000000 ). The unintentionally leads at a sufficiently implemented convert Unix Time to Date and Time to a value before the POSIX Epoch ( January 1, 1970 ) is located. This problem is known in the software development as a counter overflow.

Left unchecked, the economic impact could sometimes be harmful, especially in the banking and insurance sectors Unix systems alongside mainframes are standard. In addition to the Unix servers many embedded systems work with Unix -like operating systems, the use of time is often a multiple of desktop and server systems ( eg routers and electronic measuring devices). An at least delayed, in the long term but necessary adaptation and modernization of appropriate computer systems in businesses and institutions today's time, the probability of failure could be from certain points appear as rather low - it is, for example, generally in the interest of the company to meet customer needs and so if necessary, to create newer digital services and products and / or further develop. For example, many banks ( in Germany ) have been offering electronic means and ways of account management (see also online banking); the relevant company range computer systems must be efficient enough to meet the demands of modern customers can - this fact manifests itself possibly also in the use of x86-64-/IA-64-Prozessoren that can provide speed advantages, especially in großzahligen operations and now simply replace all 32- bit processors.

An example of typical year -2038 errors are transactions whose validity is derived from the timestamp of the result field. If the result is less than the output data, it is still waiting for a valid result or initiate the transaction at some point automatically. At the date of the year -2038 problem, however, all the results will be wearing the supposed time stamp in December 1901, ie they are always older than the input data. Waiting programs fall so easily in an infinite loop, which has applications could express to the end user in the "hanging ".

Remedy

Well before the year 2038 the Unix time count is expected to be implemented in the systems as a 64- bit counter. This is due to that the unix typical C- definition on the basis of type "long" refers to. It has already enforced in the Unix environment that changes during the transition from 32 -bit to 64 - bit architectures, this very basic type to 64 bits ( technically: conversion from ILP32 on LP64 model), so that timestamps at least by the system as a 64- bit come - time_t. Due to the 64 -bit conversion of the POSIX timestamp can operate reliably 292 billion years, without causing an overflow.

Nevertheless, a sufficient change to new 64- bit processor architectures ( AMD64/EM64T, Itanium/IA-64, IBM Power 5, UltraSPARC, PA -RISC, MIPS ) Here alone is not: Although you simplify the system-side adjustment, however, makes the thinning and re- translation of all programs with a rigid 32 -bit formatting not superfluous. Not all programs are already 64 -bit capable, and it is easily possible that system-supplied 64 -bit timestamps are incorrectly processed as 32 ​​-bit values ​​, so that only the lower 32 bits are used to query which then detached again at January 19, 2038 assume the value -231 = December 13, 1901.

Another remedy is the conversion of programs from the Unix time counter to a new time base; is already distributed about the count of milliseconds or microseconds, with 64-bit counters ( not necessarily a 64 -bit architecture requires ), in particular in embedded systems with real time requirements of this magnitude. Newer time APIs always use a greater accuracy and range than the Unix time, such as Java System.currentTimeMillis (64 -bit milliseconds since January 1, 1970). System.DateTime.Now.Ticks NET (64 -bit 10000stel milliseconds since 1 January 0001). The database-driven transactions often use TIMESTAMP values ​​that are defined in the database standard SQL92 with an accuracy in microseconds ( also as accessible in ODBC / JDBC) takes place and their representation in databases usually as thoughts away from the counter ( SQL DATE), the day counter in 32 bit is a larger span has ( the epoch underlying the day counter is very different). Where these data types continue to be used consistently for time stamps in the program, the limitations of the Unix time - counter to pick up.