Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Year 2038 problem
05-23-2010, 09:52 PM,
Information  Year 2038 problem
Year 2038 problem

The year-2038 bug is similar to the Y2K bug in that it involves a time-wrap problem not handled by programmers. In the case of Y2K, many older machines did not store the century digits of dates, hence the year 2000 and the year 1900 would appear the same.

Of course we now know that the prevalence of computers that would fail because of this error was greatly exaggerated by the media. Computer scientists were generally aware that most machines would continue operating as usual through the century turnover, with the worst result being an incorrect date. This prediction withstood through to the new millennium. Affected systems were tested and corrected in time, although the correction and verification of those systems was monumentally expensive.

There are however several other problems with date handling on machines in the world today. Some are less prevalent than others, but it is true that almost all computers suffer from one critical limitation: Most programs work out their dates from a perpetual second counter - 86400 seconds per day counting from Jan 1 1970. A recent milestone was Sep 9 2001, where this value wrapped from 999'999'999 seconds to 1'000'000'000 seconds. Very few programs anywhere store time as a 9 digit number, and therefore this was not a problem.

Modern computers use a standard 4 byte integer for this second count. This is 31 bits, storing a maximum value of 231. The remaining bit is the sign. This means that when the second count reaches 2147483647, it will wrap to -2147483648.

The precise date of this occurrence is Tue Jan 19 03:14:07 2038. At this time, a machine prone to this bug will show the time Fri Dec 13 20:45:52 1901, hence it is possible that the media will call this The Friday 13th Bug.

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

Because most 32-bit Unix-like systems store and manipulate time in this format, it is usually called Unix time, and so the year 2038 problem is often referred to as the Unix Millennium Bug. However, any other non-Unix operating systems and software that store and manipulate time this way will be just as vulnerable.

Early problems

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


There is no straightforward and general fix for this problem for existing CPU and operating system combinations, existing file systems, or existing binary data formats. Changing the definition of time_t data type to a 64-bit type would break binary compatibility for software, data storage, and may affect any code that deals with the binary representation of time. Changing time_t to an unsigned 32-bit integer, effectively allowing timestamps to be accurate until the year 2106, would affect programs that deal with time differences or dates before 1970, and thus would also break binary compatibility in many cases.

Most operating systems for 64-bit architectures already use 64-bit integers in their time_t, and these operating systems are becoming more common, particularly in desktop and server environments. Using a (signed) 64-bit value introduces a new wraparound date that is over twenty times greater than the present age of the universe: approximately 292 billion years from now, on Sunday, December 4, 292,277,026,596 AD.[2] As of 2007, however, hundreds of millions of 32-bit systems are deployed, many in embedded systems, and it is far from certain that they will all be replaced by 2038. Additionally, 32-bit applications running on 64-bit systems are likely to be affected by the issue.

Despite the modern eighteen-to-twenty-four-month generational update in computer systems technology, embedded computers may operate unchanged for the life of the system they control. The use of 32-bit time_t has also been encoded into some file formats, which means it can live on for a long time beyond the life of the machines for which such file formats were originally designed.

Alternative proposals have been made (some of which are in use) including storing either milliseconds or microseconds since an epoch (typically either 1 January 1970 or 1 January 2000) in a signed-64 bit integer, providing a minimum of 300,000 years range. Other proposals for new time representations provide different precisions, ranges, and sizes (almost always wider than 32 bits), as well as solving other related problems, such as the handling of leap seconds.
05-23-2010, 10:09 PM,
RE: Year 2038 problem
Ah the timestamp crisis is getting a little coverage now. It seems plausible but I'm sure we can avoid it with some better practices now and patch up some databases to migrate the fields that may cause issues. I wonder how long the procrastination will last.

Isn't there a 2036 asteroid problem as well? Maybe a solar flare will wipe out electronics so it'll be a moot point? We could go on about likely and unlikely end game scenarios but at least this one is something we can do something about relatively easily compared to, for instance, a roving black hole or planet.

Fear interferes with constructive thought and therefore is destructive in of itself. Live in the now, do your best in all you do, don't turn a blind eye to your brothers and sisters. Fuck fear.
There are no others, there is only us.

Possibly Related Threads...
Thread Author Replies Views Last Post
  Free 1 year American Free Press online subscription! capnchronic 1 325 12-14-2013, 10:40 PM
Last Post: temp9
  2012: HAPPY NEW YEAR!!! Solve et Coagula 0 439 12-31-2011, 02:36 PM
Last Post: Solve et Coagula
Video Family Court Judge, beats 16-year-old disabled daughter drummer 0 633 11-02-2011, 05:22 PM
Last Post: drummer
  2-year-old girl run over twice in China. rockingtheboat 12 2,599 10-28-2011, 06:42 AM
Last Post: p4r4
  Man killed 2 year old during World Cup game drummer 6 1,610 05-17-2011, 07:00 AM
Last Post: Mike_Smith
  So Its NEW YEAR 2011, Any comments on prosperity? Weyland 2 710 01-01-2011, 11:08 PM
Last Post: Weyland
  HAPPY NEW YEAR simy 2 824 12-10-2010, 02:50 AM
Last Post: beardown50
  Pole dancing for nine-year-olds? TriWooOx 1 662 08-03-2010, 07:44 AM
Last Post: Justinfinity
  SoCal Martial Law Alerts (SCMLA) has been in existence for a year and a half and this --- 0 466 06-16-2010, 02:41 PM
Last Post: ---
  Lotus plant grown from 700-year-old seed --- 9 1,266 05-07-2010, 12:07 AM
Last Post: kevlar

Forum Jump:

Users browsing this thread: 1 Guest(s)