Year 2038 = problem

From Wikipedia, the free encyclopedia

Jump to: navigatio= n, search

Example showing how the date would = reset,=20 represented as a signed 32bit integer (at 03:14:08 UTC on 19 January=20 2038).

The year 2038 problem (also known as the Unix Millennium=20 Bug^{[citation=20
needed]}, Y2K38 or Y2.038K^{[citation=20
needed]} by analogy to the Y2K problem) may = cause some=20 computer=20 software to fail at some point near the year 2038.=20 The problem affects all software and systems that both store system time as a = signed = 32-bit=20 integer, and interpret this number as the number of seconds since = 00:00:00=20 UTC = on Thursday, 1 January 1970.^[1]=20 The furthest time that can be represented this way is 03:14:07 UTC = on=20 Tuesday, 19 January 2038.^[2]=20 Times beyond this moment will "wrap around" and be stored internally as = a=20 negative number, which these systems will interpret as a date in 1901 = rather=20 than 2038. This is caused by integer=20 overflow. The counter "runs out" of usable digits, "increments" the = sign bit=20 instead, and reports a maximally negative number (continuing to count = up,=20 toward zero). This will likely cause problems for users of these systems = due to=20 erroneous calculations.

Further, while most programs will only be affected in or very close = to 2038,=20 programs that work with future dates will begin to run into problems = much=20 sooner. For example, a program that works with dates 20 years in the = future will=20 have to be fixed no later than in 2018.

Because most 32-bit Unix-like=20 systems store and manipulate time in this format, it is usually called = Unix time, and so = the year=20 2038 problem is often referred to as the Unix Millennium Bug.

[edit]=20 Early = problems

In May 2006, reports surfaced of an early manifestation of the Y2038 = problem=20 in the AOLserver software. = The=20 software was designed with a kludge=20 to handle a database request that should "never" time out. Rather than=20 specifically handling this special case, the initial design simply = specified an=20 arbitrary time-out=20 date in the future. The default configuration for the server specified = that the=20 request should time out after one billion seconds. One billion seconds=20 (approximately thirty-two years) after 9:27.28 pm on 12 May 2006 is = beyond=20 the 2038 cutoff date. Thus, after this time, the time-out calculation = overflowed=20 and returned a date that was actually in the past, causing the software = to=20 crash. When the problem was discovered, AOL server managers had to edit = the=20 configuration file and set the time-out to a lower value.^[3][4]

[edit]=20 Vulnerable = systems

Embedded=20 systems are most likely to be affected by the 2038 bug. = Telecommunication=20 systems and transportation systems from flight to automobiles = increasingly use=20 embedded systems. Automobiles, electric vehicles, and hybrid vehicles = are=20 increasingly using embedded systems to maximize efficiency and reduce = pollution.=20 Other automotive safety systems include anti-lock braking system (ABS),=20 electronic stability control (ESC/ESP), traction control (TCS) and = automatic=20 four-wheel drive. New aircraft contain advanced avionics such as = inertial=20 guidance systems and GPS receivers that also have considerable safety=20 requirements. Another major use of embedded systems is in communications = devices, including cell phones and Internet appliances (routers, = wireless access=20 points, etc.) which rely on storing an accurate time and date and are=20 increasingly based on subsets of UNIX (Android, Apple iOS, "light" = versions of=20 Linux, etc.).

As of 2011^[update],=20 most embedded systems use 8-bit=20 or 16-bit microprocessors= ,=20 even as desktop systems are transitioning to 64-bit=20 systems. Despite the modern 18=E2=80=9324-month=20 generational update in computer systems technology, embedded systems are = designed to last the lifetime of the machine in which they are a = component. It=20 is conceivable that some of these systems may still be in use in 2038. = It may be=20 impractical or, in some cases, impossible to upgrade the software = running these=20 systems, ultimately requiring replacement if 32-bit time_t=20 limitations are to be corrected.

The use of 32-bit time_t has also been encoded into some = file=20 formats^{[citation=20
needed]}, which means it can live on well beyond the = life of=20 the machines on which such file formats were originally supported.

[edit]=20 Data=20 structures with time problems

Many data structures in use today have 32-bit time representations = embedded=20 into their structure. A full list of these data structures is impossible = to=20 derive but there are well-known data structures that have the Unix time=20 problem.

file systems (like many inode=20 file systems still in use)
databases (that have 32-bit time fields)
COBOL=20 databases from the 1970s, 1980s and 1990s that have not been replaced = by=20 2038-compliant systems
embedded factory, refinery control and monitoring subsystems
assorted medical devices
assorted military devices

Each one of these places where data structures using 32-bit time are = in place=20 has its own risks related to failure of the product to perform as = designed.

[edit]=20 Solutions

There is no universal solution for the Year 2038 problem. Any change = to the=20 definition of the time_t data type would result in code=20 compatibility problems in any application in which date and time=20 representations are dependent on the nature of the signed 32-bit = time_t=20 integer. For example, changing time_t to an unsigned 32-bit = integer,=20 which would extend the range to the year 2106, would adversely affect = programs=20 that store, retrieve, or manipulate dates prior to 1970, as such dates = are=20 represented by negative numbers.

Most operating=20 systems designed to run on 64-bit=20 hardware = already use signed 64-bit time_t integers, effectively = eliminating the=20 Year 2038 problem in any software that has been developed to use the = extended=20 format. Using a signed 64-bit value introduces a new wraparound date = that is=20 over twenty times greater than the theorized age of the = universe:=20 approximately 292 billion years from now, at 15:30:08 on Sunday, 4 = December=20 292,277,026,596. The ability to make computations on dates is limited by = the=20 fact that struct tm uses a signed 32 bit int value for the = year.=20 This limits the year to a maximum of 2,147,485,547.

Alternative proposals have been made (some of which are in use), such = as=20 storing either milliseconds=20 or microseconds since = an ep= och=20 (typically either 1 January 1970 or 1 January 2000) in a signed-64 bit = integer,=20 providing a minimum of 300,000 years range.^[5][6]=20 Other proposals for new time representations provide different = precisions,=20 ranges, and sizes (almost always wider than 32 bits), as well as solving = other=20 related problems, such as the handling of leap=20 seconds.

[edit]=20 See also

System time
Unix=20 billennium
Unix=20 time
Year=20 2000 problem

[edit]=20 References

^<= /B>=20 "The Open Group Base Specifications Issue 6 IEEE Std = 1003.1,=20 2004 Edition (definition of epoch)". IEEE and The Open = Group. The=20 Open Group. 2004. http://www.opengroup.org/onlinepubs/000095399/. Retrieved 7 March = 2008.

^=20 Diomidis Spinellis (2006). Code quality: the open source = perspective..=20 Effective software development serie in Safari = Books Online (illustrated ed.). Adobe Press. = ISBN 0321= 166078. http://books.google.es/books?id=3DvEN-ckcdtCwC&pg=3D= PA49&dq=3D292,277,026,596&cd=3D1#v=3Donepage&q=3D292%2C277%2C= 026%2C596&f=3Dfalse.

^<= /B>=20 "The Future Lies Ahead". 28 June 2006.=20 http://substitute.livejournal.com/1430908.html. Retrieved 19 November = 2006.

^<= /B>=20 Weird "memory leak" problem in AOLserver = 3.4.2/3.x 12 May=20 2006

^<= /B>=20 "Unununium Time". Archived from the = original=20 on 4 August 2006. http://web.archive.org/web/20060408161959/http://unununi= um.org/articles/uuutime. Retrieved 19 November = 2006.

^<= /B>=20 Sun Microsystems. "Java API documentation: = System.currentTimeMillis". http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System= .html#currentTimeMillis(). Retrieved 7 May = 2007.

[edit]=20 External = links

Entry in How Stuff Works

The Project 2038 Frequently Asked Questions

Critical dates 2038

A=20 2038-safe replacement for time.h on 32 bit systems

v =C2=B7=20 d =C2=B7=20 e
Year-related=20 problems

Decimal or BCD = storage=20 related
Year=20 1900 problem =C2=B7 Year=20 2000 problem =C2=B7 Y1C=20 Problem =C2=B7 Year 10,000=20 problem

Binary storage = related
2036=20 NTP wraparound =C2=B7=20 Year 2038 = problem

Ti= me=20 formatting and storage bugs =C2=B7=20 Time=20 code ambiguity =C2=B7 Ep= och

Retrieved from "http://en.wikipedia.org/w/index.php?title=3DYear_2038= _problem&oldid=3D465669356"

Categories: =

Unix

Operating=20 system technology

Time=20 formatting and storage bugs

Programmi= ng=20 bugs

Future=20 problems

2030s
<= /DIV>
Hidden = categories:=20

All=20 articles with unsourced statements

Articles=20 with unsourced statements from December 2011

Articles=20 containing potentially dated statements from 2011

All=20 articles containing potentially dated statements

Use=20 dmy dates from August 2010

Year 2038 = problem

Contents

[edit]=20 Early = problems

[edit]=20 Vulnerable = systems

[edit]=20 Data=20 structures with time problems

[edit]=20 Solutions

[edit]=20 See also

[edit]=20 References

[edit]=20 External = links

Personal tools

Namespaces

Variants

Views

Actions

Search

Navigation

Interaction

Toolbox

Print/export

Languages