THE Place for Y2038 Information and Help
Y2038 Countdown:

Home   Reviews   Links   Contact Us   About Y2038.COM

Y2038 Frequently Asked Questions (FAQ)
Have a Y2038 question you'd like answered? Email faq@y2038.com

What is Y2038?
How did Y2038 originate?
How is Y2038 related to Y2K?
What are the major technical areas in which Y2038 issues may exist?
How big is Y2038? How much will it cost to prepare for Y2038?
What's the worst that could happen?
Why haven't I heard about Y2038 before?
I'll be retired or dead by the year 2038. Why should I care about Y2038?
Won't most computers have 64-bit CPUs long before 2038?
Will buying all new Y2038-compliant hardware and software before 2038 avoid any issues?
I'm an architect/programmer. What are some solutions and how do I make my code Y2038-compliant?
What programming languages are affected by Y2038?
Can I just recompile my 32-bit program on a 64-bit compiler to fix the problem?
How much of my code will likely be affected by Y2038?
Are there any software tools that can help with finding and correcting Y2038 issues?
Are there any other roll-over dates to be concerned with?
Where can I find other Internet sites that focus on Y2038 issues?
What will happen to Y2038.com after 2038?

What is Y2038?

Y2038 refers to an issue that exists because of the way time is fundamentally represented on most computers.

Most software uses time in one way or another. Software might do something simple, like display the current time, or something more complex, like time a chemical process in a manufacturing plant. To get the current time, a software program typically makes a call to the 'time()' function in C/C++, or a similar function in other languages. The value returned by this function is a 'time_t' which on 32-bit systems is usually defined as a 32-bit signed integer representing the number of seconds since Jan 1, 1970 (this date is referred to as the 'epoch'). The problem is that the range for the 32-bit signed integers is limited. Dates and times beyond early 2038 (exactly 3:14:07 AM GMT on January 19,2038), cannot be represented because the number of seconds since the epoch will exceed the largest positive value that can be held by a 32-bit signed integer. This could potentially cause problems with any non-Y2038-compliant systems and software that use time.

To help better understand the issue, a brief computer science lesson is useful. The binary representation of an integer is a series of bits, and each bit is either 0 or 1. For example, a three-bit integer can contain 2*2*2=8 unique bit patterns: 000, 001, 010, 011, 100, 101, 110, and 111. If the three bits represent an unsigned integer, the values represented by the bits are just 0, 1, 2, 3, 4, 5, 6, and 7, so the range is 0 to 7. If one is added to 7, the resulting value "wraps" back around to 0. In other words, 7 + 1 = 0.

In order to represent negative numbers, computers use something called "2's complement". This representation uses one bit for the sign of the number, so the magnitude of the range is halved. For the example above, the values of the 8 unique bit patterns in 2's complement are: 0, 1, 2, 3, -4, -3, -2, and -1, in that order. The range in this case is -4 to 3. If one is added to 3 in 2's complement math (with 3-bit signed integers), the resulting value is -4. In other words, 3 + 1 = -4. The result has 'wrapped' from the most positive value to the most negative value just by adding 1.

Extending this example to 32-bit integers, the range of 32-bit signed integers is -2,147,483,648 to 2,147,483,647. When a 32-bit signed integer represents a number of seconds, the amount of time that can be represented is approximately +/- 68 years, 19 days. Adding the maximum positive value to Jan 1, 1970 equates to 3:14:07 AM on Jan 19, 2038. After this time, the largest number of representable seconds will be exceeded, causing a 2's complement wrap condition.

What will happen then? Depending on the specific implementation of a given system's time function and the way the time value is used by software, the value returned may be interpretted as near Dec. 1901 (Jan 1, 1970 - 68 years, 19 days), or perhaps near the epoch (Jan 1, 1970). The software may then display the wrong time, write the wrong value to a database, crash, or fail in other subtle (or not so subtle) ways. Some forward looking software, such as mortgage calculation programs, may have already started encountering Y2038 issues.

Of course, 2038 is still a long way off, and most new desktop and server systems already have 64-bit hardware and operating systems. Y2038 does not affect 64-bit computers running 64-bit operating systems running properly written 64-bit applications. Y2038 also does not affect software which does not use time in any way. Note that using a 64-bit operating system (such as a 64-bit version of Windows XP, Linux, or Apple Mac with OSX), can still have Y2038 issues if applications are improperly written. Also note that most 64-bit systems can also run or emulate 32-bit software which may not be Y2038-compliant.

While 64-bit systems are gaining market share, most computers and software that exist today (2011) are not Y2038-compliant and will likely have some problems related to Y2038 if they are still running in 2038. This includes all computers running 32-bit versions of Microsoft Windows, Linux, UNIX, and other 32-bit operating systems. More significantly, it also includes the countless embedded systems which are increasingly used in modern electronic devices.

It should be mentioned that not all computer systems and software use the same epoch. For example, Apple Macs running early versions of OSX use a 32-bit unsigned integer for time and a starting date of Jan 1, 1904. These Macs are generally unaffected by Y2038, but they have a similar problem associated with Feb 6, 2040 at 6:28:15 AM. There are a surprising number of other time-related computer issues (see this link), although none are expected to be as critical as Y2038.

How did Y2038 originate?

When UNIX was first being written back around 1970, engineers at AT&T/Bell Labs needed a general purpose function to provide the current time, so they wrote one and logically called it "time". This function initially returned the current time as the number of 1/60th second intervals since Jan 1, 1971, which caused a wrap condition after just 2.5 years. The function was patched several times, and eventually took its most enduring form, returning a 32-bit signed value holding the number of seconds since the epoch of Jan 1, 1970.

You might wonder why 32-bits was chosen to represent time instead of 64-bits. After all, there's no technical reason why the UNIX designers couldn't have initially chosen to use 64-bits for time. Basically, the main reasons were hardware cost and availability. At the time, computers were extremely expensive, so limiting the representation of time to 32 bits seemed like an acceptable tradeoff. In retrospect, it was clearly not the best choice. Those early designers surely must not have realized the magnitude of the problem they were going to cause by their decision. Either that, or they had a very warped sense of humor.

As the saying goes, the rest is history. AT&T/Bell Labs UNIX became a de facto standard, and most major vendors in the computer industry adopted the same representation of time as AT&T UNIX. These included all UNIX platforms, 32-bit Linux, the IBM PC, DOS, all versions of Windows (prior to 64-bit versions), and all compilers and other tools that support these platforms.

How is Y2038 related to Y2K?

Both Y2038 and Y2K are time-related issues, but Y2K refers to the easily understood issue of the rollover from 1999 to 2000, whereas Y2038 is an issue with the binary representation of time itself. All software in which Y2K caused issues will also be affected by Y2038. Y2K was expensive and time-consuming to mitigate, and Y2038 will be as well. Unfortunately, most Y2K issues were addressed without fixing Y2038 issues. Any software that was certified for Y2K (and still in use in 2038) will need to be re-certified for Y2038-compliance. Like Y2K, all mission-critical systems will need to be certified as Y2038-compliant, particularly those involved with public safety, even systems that are comprised of 64-bit CPUs running 64-bit operating systems with 64-bit applications.

What are the major technical areas in which Y2038 issues may exist?

Potential issues exist anywhere that a 32-bit signed time value may be used. These include (but not limited to):
-Computer hardware, particularly systems with 32-bit CPUs
-Internal and external peripheral components
-Operating systems, particularly those targeting 32-bit CPUs or supporting 32-bit applications
-File systems
-Device drivers, particularly those targeting 32-bit hardware and operating systems
-Application software
-Development tools
-Web-based applications and web content
-Computer bus and communication protocols
-Communication and networking equipment (satellites, routers, switches, etc),
-Mobile electronics, including smart phones, feature phones, tablets, netbooks PDAs, GPS, etc.
-Transportation systems, such as aircraft, automobiles, ships, elevators, traffic lights, etc.
-Home electronics, such as TVs, stereos, game consoles, security systems, sprinkler systems, etc.
-Other embedded systems, such as medical devices, industrial equipment, cash registers, test equipment, etc

How big is Y2038? How much will it cost to prepare for it?

Y2038 is an extremely large and complex problem! One way to estimate the magnitude of Y2038 is to use Y2K as a basis. Some estimates for the total worldwide amount spent preparing for Y2K are over $1 trillion USD. Consider that Y2K affected the earliest 30 years of the Digital Age. Y2038 will mostly affect the second set of 30 years of the Digital Age (optimistically assuming all products sold after 2030 will be Y2038-compliant). There will be several orders of magnitude more computers, software, etc. put into service from 2000-2030 compared to 1970-2000. Thus, it follows that the effort required to prepare for Y2038 will be at least several times larger than Y2K. Taking into account inflation as well, the total worldwide cost of preparing for Y2038 will easily exceed $10 trillion USD.

What's the worst that could happen?

The worst-case Y2038 scenarios are more or less the same as the worst-case scenarios predicted for Y2K. In fact, the chances of catestrophic events are much greater for Y2038 than Y2K since Y2038 is fundamental to the representation of time within computers, whereas Y2K was mostly just an issue of time interpretation by humans. Electric power plants could go off line. Cars may not start or behave erratically. Global communication could come to a halt. The Internet could entirely or partially stop working. Satellites may cease to function and possibly fall out of orbit. Many embedded devices may malfunction. The use of 32-bit time values stored in databases could easily cause a fair amount of confusion until the problems are resolved. Fortunately, there is plenty of time left to mitigate these potential issues.

Why haven't I heard about Y2038 before?

There may be several reasons. One reason is of course that the Y2038 event seems so far off. Being over 26 years away, there is no sense of immediate urgency to fix anything. However, this is the same type of thinking that created the Y2038 issue to begin with.

Another reason you may not have heard about Y2038 is probably due to the extensive media coverage that preceded Y2K. Perhaps in part due to the heightened awareness by mainstream media, the Y2K issue was almost fully mitigated prior to Jan 1, 2000.  When Jan. 1, 2000 arrived, there were no catastrophes, and there was a public sense that the Y2K event had been over-hyped. In fact, it is likely that the extensive media coverage for Y2K forced businesses to thoroughly and proactively address it.

Yet another reason may be a general lack of understanding of Y2038. Y2K was fairly easy to understand, but Y2038 requires a deeper understanding about the digital representation of time in computers.

I'll be retired or dead by the year 2038.  Why should I care about Y2038?

Crazy as it sounds, this question comes up a lot when discussing Y2038. There are many reasons to care about Y2038. For one, your children and grandchildren will hopefully be very much alive in 2038. Surely you should care about the future for their sake. Consider how shortsighted our generation (and our parents and grandparents for that matter) will seem to our children when they are faced with the staggering burdon of addressing Y2038.

Won't most computers have 64-bit CPUs long before 2038?

Indeed, almost all new servers and many desktop computers being sold today (2011) have 64-bit hardware and operating systems. Indications are that most new desktop and laptop PCs sold by 2015 will contain 64-bit CPUs.  But remember that the CPU is only one part of the Y2038 issue.  In addition to the computer hardware, there are many other technical areas where there may be Y2038 issues, including the operating system, application software, peripheral hardware, device drivers, file systems, databases, communication protocols, web content, and embedded systems. PCs using 64-bit CPUs will still be capable of running 32-bit software which may not be Y2038-compliant. Even 64-bit software may not be Y2038-compliant.

It is also important to consider that most of the billions of embedded systems today and the trillions that will exist by 2038 will still be using 32-bit (or less) CPUs due to factors such as power usage and the higher cost and complexity of 64-bit CPUs. Of course, many embedded systems will not experience Y2038 issues, but a significant portion of them may.

Will buying all new Y2038-compliant hardware and software before 2038 avoid all Y2038 issues?

Purchasing new hardware/software (in uses where it is available) is a pragmatic step of an overall Y2038 strategy, but there will still be many legacy issues to deal with, such as existing databases and file systems with binary 32-bit data fields for time.

Most vendors of computer-related hardware and software should plan to certify all of their products as Y2038-compliant long before Y2038. The best type of certification is when vendors state explicitly how long a product will run properly. For example, 'Y10K Compliant' would mean no date problems through at least the year 10,000.

I'm an architect/programmer. What are some solutions, and how do I make my code Y2038-compliant?

There is no universal solution to Y2038. Depending on various constraints, some options are available, each with its own advantages and disadvantages.

Moving to Y2038-compliant 64-bit hardware platform, OS, and tools is the simplest solution if feasible. This provides a 64-bit time_t, as well as the standard time-related functions that work with it. Existing code still needs to be checked for Y2038 issues. Y2038-compliant versions of any third-party libraries should also be used.

In some systems, it may be possible to change the definition of time_t from 'int' to 'unsigned int', extending the range out by 68 years to 2106. This would break time comparisons prior to the epoch. A new (32-bit) version of the time library would be needed. All calls to standard time functions would need to be replaced with the new functions.

It may be feasible in some existing systems to store additional time bits in flash memory. Each extra bit doubles the amount of time that can be represented, so adding even a single bit would extend the time by another 68 years to 2106. A new library of 64-bit time-related functions would be needed, and all calls to the standard time functions would need to be replaced with 64-bit versions.

Another possibility is to consider the approach envisioned for Network Time Protocol version 5 (NTP). Version 4 of NTP uses 32 bits (unsigned) of seconds along with 32 bits of fractional seconds. This version will experience a wrap condition in the year 2036. Version 5 of NTP will likely use 64 bits of seconds and 64 bits of fractional seconds. To use this approach for addressing Y2038 would require a new time-related function library to support this time format, as well as more complex changes to existing code.

One website details an approach referred to as pivotal time, described here. This technique assumes the current time will wrap back to 1901, but is interpretted to mean +/- 68 years from the actual time.

In new system designs, hardware should always be designed to support time values larger than 32-bits, even if the CPU is 32-bits. This will make it easier to provide 64-bit time functions.

Part of most any solution is that all source code should be checked for all uses of time in order to assure Y2038-compatibility. For example, in "C", all instances of time_t and time-related functions must be carefully reviewed. Values of type time_t should never be cast or stored into a type 'long' variable since 'long' is 32-bits on most platforms.

You might notice that using 64-bits to hold seconds is actually quite wasteful since the time represented by a 64-bit signed quantity of seconds is around 292 billion years, which is quite a few times the estimated age of the universe! Practically speaking, it would be much more useful for the 64 bits to represent a time value for the number of milliseconds or microseconds since the epoch. A 64-bit signed value in milliseconds can hold approx. +/- 292 million years, while a 64-bit signed value in microseconds can hold approx +/- 292,000 years.

It would also be convenient if the epoch were to be redefined as midnight on Jan. 1, 0000. However, since these modifications would require changing solidly established industry standards (not to mention even more extensive coding changes), such improvements will most likely not be broadly accepted.

What programming languages are affected by Y2038?

Every programming language is potentially affected by Y2038. While "C" was the initial computer language in which the problem was introduced, most other programming languages adopted the same representation for current time. (If you know of any programming language that is unaffected by Y2038, please let us know!). Actually, most computer languages follow the conventions established on a given platform. For example, Mac applications (prior to OSX) are susceptible to the Mac's Y2038-like issue in the year 2040, regardless of the language used to write the application.

Can I just recompile my 32-bit program on a 64-bit compiler to fix the problem?

Probably not. It depends (among other things) on the targeted hardware and the nature of the program. The chance of simply recompiling a program to fix the Y2038 issue is remote.

How much of my code will likely be affected by Y2038?

Of course, the answer is highly dependent on the software in question. Software that uses time extensively will obviously require more changes than software that doesn't use time as much. As a rough guideline, it has been estimated that ~6% of all source code needed to be reviewed for Y2K issues. The percent of source code that may be affected by Y2038 should be around the same, or slightly higher.

Are there any software tools that can help with finding and correcting Y2038 issues?

Based on the shear magnitude of Y2038, many tools will undoubtedly be marketed. Programmers should approach such tools with discretion since there will undoubtedly be vendors that try to take advantage of the fear, uncertainty, and doubt about Y2038 in order to make a quick profit with sub-standard or worthless tools. We intend to review as many Y2038-related products as possible and keep an up to date list with reviews here.

Are there any other roll-over dates to be concerned with?

Yes. There are a surprising number of other time-related computer issues (see this link), although none are expected to be as critical as Y2038. For example, Apple Mac computers running versions of the Apple MacOS prior to OSX will have a time rollover similar to Y2038 on February 6, 2040. The date is different than Y2038 because the MacOS uses a different epoch (Jan 1, 1904) and 32-bit unsigned value for time, rather than a signed value. There is also an issue with the Network Time Protocol (NTP) which will have a rollover event in 2036. This could affect operation of the Internet and serve as a last-chance call to action for Y2038.

Where can I find other Internet sites that focus on Y2038 issues?

Google is your friend. We also maintain a links page here.

What will happen to Y2038.com after 2038?

2038 is still a long way off, and many factors could obviously impact future plans. The current plan is to evolve Y2038.com into a software services and consulting company (with a different name to be determined) that will exist long after 2038. The new company will continue to support latent Y2038 issues and the y2038.com website.

All information on this website is Copyright (C) 2000-2011, y2038.com. All rights reserved.