FAQ

Y2038 refers to an issue related to the way time is handled by computers. Time is often represented as the number of seconds since Jan 1, 1970. Whenever a 32-bit signed integer is used for this, the maximum value that can be represented is +/- ~68 years, 19 days from the epoch, which corresponds to Jan 19, 2038. What happens after that is system dependent, but generally not good. A computer may act as if its time got reset to Dec 1901, or possibly to the epoch of Jan 1, 1970. It may give unexpected results or crash.

Basically, any software that uses time in any way may potentially have Y2038 issues. While only a small percentage of each software component is typically affected, this is still enough to cause many problems. Embedded systems with 32-bit cores and computers running 32-bit versions of Linux and Windows and are particularly at risk, but even 64-bit computer systems may have problems. In 64-bit computer systems, time can be represented in 64-bit integers, but Y2038 issues may still exist in applications, device drivers, databases, storage systems, and network protocols.

There may be several reasons. One reason is of course that the Y2038 event seems so far off. Being over 20 years away, there is no sense of immediate urgency to fix anything. However, this is the same type of thinking that was partly responsible for the creation of 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 Y2K media coverage forced businesses to thoroughly and proactively address it. (Chances are, media coverage will similarly increase before 2038).

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.

Indeed, virtually all new servers, desktop, and laptop computers being sold today have 64-bit hardware and operating systems. Some high-end cell phones and tablets also have 64-bit hardware and operating systems.  However, the hardware and operating system are only part of the Y2038 issue. There are many other technical areas where Y2038 issues may exist, including application software, peripheral hardware, device drivers, file systems, databases, communication protocols, web content, and embedded systems. Computers with 64-bit hardware and operating systems are 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 likely 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. Many embedded systems will not experience Y2038 issues, but a significant portion of them may.

Purchasing new hardware and software is a pragmatic and relatively simple part of an overall Y2038 compliance strategy, but there are also many legacy issues to deal with, such as existing databases, file systems, and communication protocols with binary 32-bit data fields for time. Furthermore, 64-bit systems are capable of running 32-bit software, either directly or within virtual environments, and these may not be Y2038-compliant. There is also the issue of all internally developed software for business use and contained within products which may have Y2038 issues, but that can't simply be purchased.

It depends. If your company's products and/or services use time and have a 20+ year life cycle, then the answer is definitely yes. Examples are satellites, power plants, airplanes, trains, elevators, pace makers, life insurance, and mortgage services. If your products  have a much shorter life cycle, then you still have some time. Just realize that the results of many projects may get used for longer than expected.

We suggest making Y2038 compliance a requirement for all new projects, and test for it. Starting early allows plenty of time to identify dependencies on third-party products and contact those vendors for Y2038-compliant replacements, or find alternate vendors. It is much better to be proactive about Y2038 compliance rather than waiting for customers to discover issues.

It depends.  One factor is the life-cycle of your products. For products with life-cycles of 20+ years, you should start preparing now.  For shorter life-cycles, you may be able to wait until your next development cycle, and then make Y2038 compliance a requirement.

Another factor is your business infrastructure. Most companies have business infrastructure tools and data which may have been developed in-house or purchased/leased from third-parties. These systems may be quite complex and may have taken years to deploy.  The original developers may or may not be available to assess or mitigate Y2038 issues. Therefore, the assessment/mitigation effort may be large and may include migration of data.  Companies that wait too long to prepare will be competing for limited technical resources as 2038 approaches and may find it difficult to secure the resources in time at a reasonable cost, thereby putting the business itself at risk.

The main point is that the Y2038 effort should not be underestimated. It is far better to proactively assess and mitigate as early as possible.

Here are some actions that you can consider taking now:

Designate a Y2038 Compliance Officer to serve as the company focal point for Y2038 compliance. This position may or may not be full-time depending on the size of the company. The person in this position could, for example, report to a senior officer, and also chair a committee comprised of directors/managers or representatives from every major division in the company. The person in this position will be responsible for keeping  documentation on compliance findings and status.

Implement corporate policies for Y2038 compliance. For example, a policy may require that all new projects be designed, tested, and maintained for Y2038 compliance if at all possible. The policy can further require that exceptions be formally documented and approved, thereby enabling them to be tracked and addressed sometime later.

Start assessing your company's level of exposure to Y2038. This should include all digital systems used or produced by your company, from the largest business system to the smallest embedded system. It should also include all databases and storage systems, third-party and developed system and application software, and any custom network protocols. When issues are found with third-party products, you should contact those vendors and request that they update their products to be compliant.

Budget for Y2038. The above actions cannot happen without a financial commitment from management. Postponing these actions also has a cost, likely much higher than you expect. The cost is not just money... it is also time (since issues will take longer to fix later) and employee satisfaction (since developers generally want to work on new things, not on date issues in old systems). Budgeting now will save money in the long run.

It totally depends on your needs. For new projects, the incremental cost of a requirement for Y2038 compliance (without using outsource staff) is probably trivial relative to the cost of the project. But if you have a significant existing portfolio of products and complex business systems, outsourcing may be a viable option to help with Y2038 assessment and/or mitigation, thus freeing up your prime in-house developers to continue working on forward looking projects instead of date/time issues.

Y2038 refers to an issue that exists because of the way time is fundamentally represented on many 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 to +/- 2.147 Billion. 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 or even virtual machines with 32-bit operating systems which may not be Y2038-compliant.

While 64-bit systems are gaining market share, most computers and software that exist today 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 many billions of 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 likely to be as major as Y2038.

Virtually 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. Many development platforms follow the conventions established on the 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.

Of course, the answer is highly dependent on the code 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 needs to be reviewed for Y2038 should be around the same.  But also realize that Y2038 may impact stored data in databases, file systems, network protocols, etc., so the issues may extend well beyond just the code itself.

It depends (among other things) on the targeted hardware and the nature of the program, but usually the answer is no. Any places in the code where the time in seconds is copied to a 32-bit integer will likely break or do something unexpected. The chance of simply recompiling a program to fix all Y2038 issues is remote.

This link claims that Perl is Y2038-compliant as of v5.12.0. We have not verified this. In any case, Perl (and all other) applications should still be tested.

The Java date class uses a 64-bit long for seconds, so Java itself should not have a Y2038 issue. However, Java may interface directly with the system on which it is running to get the current time. If the system itself is not Y2038-compliant, then Java apps may experience Y2038 issues. This will generally be the case for Java running on 32-bit embedded systems. Furthermore, there could be issues with file systems and communication protocols. Just as with all other software that use time in any way, Java applications will need to be checked for Y2038-compliance.  See this stackoverflow link for some additional insight.

Mac OSes prior to 10.4 used a 32-bit unsigned integer with an epoch of Jan 1, 1904 which will rollover on Feb 6, 2040.

Mac OSes including 10.4, 10.5, and 10.6 (32-bit version) for both x86 and PPC have an issue with Y2038.

Mac OSes starting with 10.7 Mavericks (aka OSX) are 64-bit with an epoch the same as Linux/Windows (Jan 1, 1970), so OSX itself does not have a Y2038 issue.  However, note that 32-bit apps (which may have Y2038 issues) can be run in OSX. There is also no inherent guarantee that 64-bit apps are Y2038 compliant.

Like all software that uses time, OSX apps must be verified to be Y2038 compliant.

See this link for more details on Mac OS epochs.

As far as we know, z/OS does not have an inherent issue with Y2038. However, z/OS will experience a rollover of its Time Of Day clock on Sept 17, 2042. Also consider that z/OS may be interfacing with other systems which do have Y2038 issues, and there may be issues with databases, storage systems, and communication protocols to take into account.

See this link for a bit more detail.

Probably not. See this link.

Yes. The TIMESTAMP data type has a range of 00:00:01 on Jan 1, 1970 to 03:14:07 on Jan 19, 2038 (UTC).

The DATETIME data type is a good alternative, having a range from  Jan 1, 1000 to Dec 31, 9999.

Also, the UNIX_TIMESTAMP() function returns 0 after 03:14:07 on Jan 19, 2038.

There is no universal solution to Y2038. Each development environment and programming language has unique issues and potential solutions. 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 part of the solution (if that is possible for your projects). This should provides 64-bit time functions. Existing code still needs to be checked for Y2038 issues. Y2038-compliant versions of any third-party libraries should also be used.

In some 32-bit systems, it may be possible to change the representation of time (e.g. 'time_t' in "C") from a signed integer to an unsigned integer, thus extending the time range another 68 years to 2106. Times prior to the epoch of Jan 1, 1970 would no longer be supported, but that may be an acceptable compromise. The time library for your environment would need to be replaced with one that uses 32-bit unsigned integers. All calls to existing time functions would need to be replaced with the new functions, and of course tested thoroughly.

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

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. Again similar to above, to use this approach for addressing Y2038 would require a new time-related function library to support this time format, as well as 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 interpreted to mean +/- 68 years from the actual current date.

In new hardware designs, the 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 extended time range functionality.

Part of almost any Y2038 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 should be carefully reviewed. For example, values of a 64-bit type time_t can inadvertently be cast or stored into 32-bit integers.

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 an 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 types of modifications would require changing broadly established industry standards (not to mention even more extensive coding changes), such improvements will most likely not be broadly accepted.

First, note that there are options for embedded systems with 32-bit CPUs to be Y2038 compliant without resorting to 64-bit CPUs. For example, a 32-bit embedded system may be able to use a 64-bit time library, or a time library with 32-bit unsigned time_t to handle dates through 2106.

Below are some 64-bit CPUs already available. 64-bit CPUs are an area of active development, so this information may become out of date quickly.

Broadcom BCM2837 - This quad-core 64-bit SoC is based on ARM Cortex-A53 and runs at 1.2GHz. It can be used for mobile devices, but it is also intended for general purpose usage. Most notably, it is the processor used in Raspberry Pi 3 which was recently announced in Feb 2016. The Raspberry Pi 3 is very impressive, at ~10x the performance and the same cost (~$35 US) as the first Raspberry Pi (which was based on a 32-bit processor and therefore susceptible to Y2038). However, all currently available operating systems for the Raspberry Pi are 32-bit. See this link for additional discussion.

Allwinner A64 - This chip is also based on ARM Cortex-A53, with a price of around $5. It is the processor being used in the Pine64, which is also impressive, selling for as little as $15.

HiSilicon Kirin 6220 - An 8-core SoC based on ARM Cortex-A53 at 1.2GHz. Used in the HiKey dev board which sells for around $99 depending on configuration.

Qualcomm Snapdragon - The 800, 600, and 400 series Snapdragon processors are almost all capable of running in 64-bit mode. Below are several of the available development boards:

1. DragonBoard 410c from Arrow Electronics for $75
2. Open-Q 600 from Intrinsyc for $165
3. DragonBoard 810 from Intrinsyc for $495

Nvidia Tegra K1 - This processor is used on the Google Nexus 9 tablet

Nvidia Tegra X1 - This processor is used in the Google Pixel C Chromebook

MediaTek MT6752- Another processor intended for mobile devices

All of the above products are based on technology from ARM Holdings. ARM offers a variety of 64-bit designs which it licenses to other companies.

Intel offers many variations of 64-bit CPUs with "Embedded Options Available". These can be listed and compared using the selection guide/chart here.

AMD offers some 64-bit CPUs for embedded use. The Wikipedia page here has a useful table.

The Global Positioning System, or GPS uses a raw date format which consists of 13-bit 'number of weeks' field and a 'seconds into the week' field, using an epoch of Jan 6, 1980 at 00:00:00 (UTC). The 'number of weeks' field will rollover after 8192 weeks (157 years), so GPS itself should not have any date/time issues until the year 2137. However, Y2038 issues may exist if the raw dates/times from GPS are improperly translated to other date/time formats, or translated to formats such as 32-bit signed integer which inherently have Y2038 issues.

See the wiki page for GPS here for more details.

In a nutshell, the answer is yes, most mobile devices have Y2038 issues, and will continue to have such issues, likely up to and including in 2038.

Most mobile devices today are based on 32-bit technology, but there is a major shift underway in the mobile device markets to move to 64-bit technology. Some high-end devices are already using 64-bit microprocessors. Chances are good that the majority of cell phones and tablets will contain 64-bit processing chips by 2038. However, using such chips does not solve all Y2038 issues, for several reasons. First, 64-bit processing chips contain multiple cores, some of which may be 32-bits. As a result, there may be Y2038 issues in the embedded system firmware exchanging dates and times between 64-bit and 32-bit cores.

Another reason why mobile devices may have Y2038 issues in 2038 has to do with the way the fact that mobile devices require precise time synchronization with the current time and may have no easy way for developers to test their applications with future dates.

Y2038 refers to an issue that exists because of the way time is fundamentally represented on many 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 to +/- 2.147 Billion. 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 or even virtual machines with 32-bit operating systems which may not be Y2038-compliant.

While 64-bit systems are gaining market share, most computers and software that exist today 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 many billions of 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 likely to be as major as Y2038.

The Java date class uses a 64-bit long for seconds, so Java itself should not have a Y2038 issue. However, Java may interface directly with the system on which it is running to get the current time. If the system itself is not Y2038-compliant, then Java apps may experience Y2038 issues. This will generally be the case for Java running on 32-bit embedded systems. Furthermore, there could be issues with file systems and communication protocols. Just as with all other software that use time in any way, Java applications will need to be checked for Y2038-compliance.  See this stackoverflow link for some additional insight.

The obvious first-order approach is to simply set the time of the system in question to a date past 2038 and see if there are issues. In some cases, this kind of 'black box' testing may work, but there are a lot of things to consider. Depending on the system, you may not be able to change the date on a live system without repercussions, so you may need to set up a sandbox in which to test. Depending on the size and complexity of the system, the time and cost to do this may be significant, but there may be no other way.

There are some commercial products available for testing future dates on Linux, Windows, and z/OS.

Mac OSes prior to 10.4 used a 32-bit unsigned integer with an epoch of Jan 1, 1904 which will rollover on Feb 6, 2040.

Mac OSes including 10.4, 10.5, and 10.6 (32-bit version) for both x86 and PPC have an issue with Y2038.

Mac OSes starting with 10.7 Mavericks (aka OSX) are 64-bit with an epoch the same as Linux/Windows (Jan 1, 1970), so OSX itself does not have a Y2038 issue.  However, note that 32-bit apps (which may have Y2038 issues) can be run in OSX. There is also no inherent guarantee that 64-bit apps are Y2038 compliant.

Like all software that uses time, OSX apps must be verified to be Y2038 compliant.

See this link for more details on Mac OS epochs.

Probably not. See this link.

Yes. The TIMESTAMP data type has a range of 00:00:01 on Jan 1, 1970 to 03:14:07 on Jan 19, 2038 (UTC).

The DATETIME data type is a good alternative, having a range from  Jan 1, 1000 to Dec 31, 9999.

Also, the UNIX_TIMESTAMP() function returns 0 after 03:14:07 on Jan 19, 2038.

The Global Positioning System, or GPS uses a raw date format which consists of 13-bit 'number of weeks' field and a 'seconds into the week' field, using an epoch of Jan 6, 1980 at 00:00:00 (UTC). The 'number of weeks' field will rollover after 8192 weeks (157 years), so GPS itself should not have any date/time issues until the year 2137. However, Y2038 issues may exist if the raw dates/times from GPS are improperly translated to other date/time formats, or translated to formats such as 32-bit signed integer which inherently have Y2038 issues.

See the wiki page for GPS here for more details.

In a nutshell, the answer is yes, most mobile devices have Y2038 issues, and will continue to have such issues, likely up to and including in 2038.

Most mobile devices today are based on 32-bit technology, but there is a major shift underway in the mobile device markets to move to 64-bit technology. Some high-end devices are already using 64-bit microprocessors. Chances are good that the majority of cell phones and tablets will contain 64-bit processing chips by 2038. However, using such chips does not solve all Y2038 issues, for several reasons. First, 64-bit processing chips contain multiple cores, some of which may be 32-bits. As a result, there may be Y2038 issues in the embedded system firmware exchanging dates and times between 64-bit and 32-bit cores.

Another reason why mobile devices may have Y2038 issues in 2038 has to do with the way the fact that mobile devices require precise time synchronization with the current time and may have no easy way for developers to test their applications with future dates.

Please see our Services page

2038 is still a long way off, and many factors could obviously impact our future plans. The current plan is to evolve Y2038.com (after 2038) 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 Y2038.com customers and the y2038.com website, and will also help with any latent Y2038 issues.

Y2038 refers to an issue that exists because of the way time is fundamentally represented on many 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 to +/- 2.147 Billion. 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 or even virtual machines with 32-bit operating systems which may not be Y2038-compliant.

While 64-bit systems are gaining market share, most computers and software that exist today 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 many billions of 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 likely to be as major as Y2038.

There may be several reasons. One reason is of course that the Y2038 event seems so far off. Being over 20 years away, there is no sense of immediate urgency to fix anything. However, this is the same type of thinking that was partly responsible for the creation of 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 Y2K media coverage forced businesses to thoroughly and proactively address it. (Chances are, media coverage will similarly increase before 2038).

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.

Indeed, virtually all new servers, desktop, and laptop computers being sold today have 64-bit hardware and operating systems. Some high-end cell phones and tablets also have 64-bit hardware and operating systems.  However, the hardware and operating system are only part of the Y2038 issue. There are many other technical areas where Y2038 issues may exist, including application software, peripheral hardware, device drivers, file systems, databases, communication protocols, web content, and embedded systems. Computers with 64-bit hardware and operating systems are 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 likely 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. Many embedded systems will not experience Y2038 issues, but a significant portion of them may.

Of course, the answer is highly dependent on the code 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 needs to be reviewed for Y2038 should be around the same.  But also realize that Y2038 may impact stored data in databases, file systems, network protocols, etc., so the issues may extend well beyond just the code itself.

Purchasing new hardware and software is a pragmatic and relatively simple part of an overall Y2038 compliance strategy, but there are also many legacy issues to deal with, such as existing databases, file systems, and communication protocols with binary 32-bit data fields for time. Furthermore, 64-bit systems are capable of running 32-bit software, either directly or within virtual environments, and these may not be Y2038-compliant. There is also the issue of all internally developed software for business use and contained within products which may have Y2038 issues, but that can't simply be purchased.

The Java date class uses a 64-bit long for seconds, so Java itself should not have a Y2038 issue. However, Java may interface directly with the system on which it is running to get the current time. If the system itself is not Y2038-compliant, then Java apps may experience Y2038 issues. This will generally be the case for Java running on 32-bit embedded systems. Furthermore, there could be issues with file systems and communication protocols. Just as with all other software that use time in any way, Java applications will need to be checked for Y2038-compliance.  See this stackoverflow link for some additional insight.

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 the high hardware cost and limited availability. At the time, computers were extremely expensive, so limiting the representation of time to 32 bits seemed like an acceptable trade-off. 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, Linux, the IBM PC, DOS, all versions of Windows (prior to 64-bit versions), and all compilers and other tools that support these platforms.

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
-Firmware/BIOS
-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
-Databases
-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.

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.

The Global Positioning System, or GPS uses a raw date format which consists of 13-bit 'number of weeks' field and a 'seconds into the week' field, using an epoch of Jan 6, 1980 at 00:00:00 (UTC). The 'number of weeks' field will rollover after 8192 weeks (157 years), so GPS itself should not have any date/time issues until the year 2137. However, Y2038 issues may exist if the raw dates/times from GPS are improperly translated to other date/time formats, or translated to formats such as 32-bit signed integer which inherently have Y2038 issues.

See the wiki page for GPS here for more details.

The worst-case Y2038 scenarios are roughly the same as those predicted for Y2K. In fact, the chance of catastrophic events is 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.

The absolute worst case scenario is one in which all infrastructure components simultaneously and completely stop working, including power utilities, transportation, satellites, communication, Internet, banking, commerce, medical devices, etc. Electric power plants could go off line. Nuclear power plants could experience core melt downs. Military munitions could misfire or become non-functional. Cars, planes, trains, boats, submarines, etc. may not start, fail abruptly, 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 devices with embedded computers may malfunction, including cell-phones, pace makers, ATMs, and stop-lights. Non-compliant databases could easily cause a fair amount of confusion until the problems are resolved.

Fortunately, there is still plenty of time left to address all of these potential issues so that hopefully no major catastrophes occur.

In a nutshell, the answer is yes, most mobile devices have Y2038 issues, and will continue to have such issues, likely up to and including in 2038.

Most mobile devices today are based on 32-bit technology, but there is a major shift underway in the mobile device markets to move to 64-bit technology. Some high-end devices are already using 64-bit microprocessors. Chances are good that the majority of cell phones and tablets will contain 64-bit processing chips by 2038. However, using such chips does not solve all Y2038 issues, for several reasons. First, 64-bit processing chips contain multiple cores, some of which may be 32-bits. As a result, there may be Y2038 issues in the embedded system firmware exchanging dates and times between 64-bit and 32-bit cores.

Another reason why mobile devices may have Y2038 issues in 2038 has to do with the way the fact that mobile devices require precise time synchronization with the current time and may have no easy way for developers to test their applications with future dates.

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-2038 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.

Crazy as it sounds, this question comes up a lot when discussing Y2038. There are many reasons to care about addressing Y2038. For one, your children and grandchildren will hopefully be very much alive in 2038. Also, not addressing Y2038 could literally cause catastrophes. 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 burden of addressing Y2038 (and potentially recovering from avoidable catastrophes if the issues are left unaddressed).

Our definitions are:

Y2038 compliance means that a given system will not have Y2038 issues to at least a specified date beyond 2038.

Y2038 certification means that an organization has certified that a given system will not have Y2038 issues and is certified to function without date-related issues to at least a specified date beyond 2038.

At the moment, there are no (known) official or even unofficial industry standards for Y2038 compliance/certification. It would be a positive development for such standard(s) to be created, and we at Y2038.com are interested in participating in the standard(s) development process. Let us know if you are also interested. Perhaps we can get the ball rolling through a grass-roots effort.

Y2038 refers to an issue related to the way time is handled by computers. Time is often represented as the number of seconds since Jan 1, 1970. Whenever a 32-bit signed integer is used for this, the maximum value that can be represented is +/- ~68 years, 19 days from the epoch, which corresponds to Jan 19, 2038. What happens after that is system dependent, but generally not good. A computer may act as if its time got reset to Dec 1901, or possibly to the epoch of Jan 1, 1970. It may give unexpected results or crash.

Basically, any software that uses time in any way may potentially have Y2038 issues. While only a small percentage of each software component is typically affected, this is still enough to cause many problems. Embedded systems with 32-bit cores and computers running 32-bit versions of Linux and Windows and are particularly at risk, but even 64-bit computer systems may have problems. In 64-bit computer systems, time can be represented in 64-bit integers, but Y2038 issues may still exist in applications, device drivers, databases, storage systems, and network protocols.

Y2038 refers to an issue that exists because of the way time is fundamentally represented on many 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 to +/- 2.147 Billion. 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 or even virtual machines with 32-bit operating systems which may not be Y2038-compliant.

While 64-bit systems are gaining market share, most computers and software that exist today 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 many billions of 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 likely to be as major as Y2038.

Virtually 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. Many development platforms follow the conventions established on the 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.

There may be several reasons. One reason is of course that the Y2038 event seems so far off. Being over 20 years away, there is no sense of immediate urgency to fix anything. However, this is the same type of thinking that was partly responsible for the creation of 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 Y2K media coverage forced businesses to thoroughly and proactively address it. (Chances are, media coverage will similarly increase before 2038).

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.

Of course, the answer is highly dependent on the code 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 needs to be reviewed for Y2038 should be around the same.  But also realize that Y2038 may impact stored data in databases, file systems, network protocols, etc., so the issues may extend well beyond just the code itself.

Indeed, virtually all new servers, desktop, and laptop computers being sold today have 64-bit hardware and operating systems. Some high-end cell phones and tablets also have 64-bit hardware and operating systems.  However, the hardware and operating system are only part of the Y2038 issue. There are many other technical areas where Y2038 issues may exist, including application software, peripheral hardware, device drivers, file systems, databases, communication protocols, web content, and embedded systems. Computers with 64-bit hardware and operating systems are 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 likely 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. Many embedded systems will not experience Y2038 issues, but a significant portion of them may.

It depends (among other things) on the targeted hardware and the nature of the program, but usually the answer is no. Any places in the code where the time in seconds is copied to a 32-bit integer will likely break or do something unexpected. The chance of simply recompiling a program to fix all Y2038 issues is remote.

Purchasing new hardware and software is a pragmatic and relatively simple part of an overall Y2038 compliance strategy, but there are also many legacy issues to deal with, such as existing databases, file systems, and communication protocols with binary 32-bit data fields for time. Furthermore, 64-bit systems are capable of running 32-bit software, either directly or within virtual environments, and these may not be Y2038-compliant. There is also the issue of all internally developed software for business use and contained within products which may have Y2038 issues, but that can't simply be purchased.

It depends. If your company's products and/or services use time and have a 20+ year life cycle, then the answer is definitely yes. Examples are satellites, power plants, airplanes, trains, elevators, pace makers, life insurance, and mortgage services. If your products  have a much shorter life cycle, then you still have some time. Just realize that the results of many projects may get used for longer than expected.

We suggest making Y2038 compliance a requirement for all new projects, and test for it. Starting early allows plenty of time to identify dependencies on third-party products and contact those vendors for Y2038-compliant replacements, or find alternate vendors. It is much better to be proactive about Y2038 compliance rather than waiting for customers to discover issues.

This link claims that Perl is Y2038-compliant as of v5.12.0. We have not verified this. In any case, Perl (and all other) applications should still be tested.

The Java date class uses a 64-bit long for seconds, so Java itself should not have a Y2038 issue. However, Java may interface directly with the system on which it is running to get the current time. If the system itself is not Y2038-compliant, then Java apps may experience Y2038 issues. This will generally be the case for Java running on 32-bit embedded systems. Furthermore, there could be issues with file systems and communication protocols. Just as with all other software that use time in any way, Java applications will need to be checked for Y2038-compliance.  See this stackoverflow link for some additional insight.

Please see our Services page

It depends.  One factor is the life-cycle of your products. For products with life-cycles of 20+ years, you should start preparing now.  For shorter life-cycles, you may be able to wait until your next development cycle, and then make Y2038 compliance a requirement.

Another factor is your business infrastructure. Most companies have business infrastructure tools and data which may have been developed in-house or purchased/leased from third-parties. These systems may be quite complex and may have taken years to deploy.  The original developers may or may not be available to assess or mitigate Y2038 issues. Therefore, the assessment/mitigation effort may be large and may include migration of data.  Companies that wait too long to prepare will be competing for limited technical resources as 2038 approaches and may find it difficult to secure the resources in time at a reasonable cost, thereby putting the business itself at risk.

The main point is that the Y2038 effort should not be underestimated. It is far better to proactively assess and mitigate as early as possible.

Here are some actions that you can consider taking now:

Designate a Y2038 Compliance Officer to serve as the company focal point for Y2038 compliance. This position may or may not be full-time depending on the size of the company. The person in this position could, for example, report to a senior officer, and also chair a committee comprised of directors/managers or representatives from every major division in the company. The person in this position will be responsible for keeping  documentation on compliance findings and status.

Implement corporate policies for Y2038 compliance. For example, a policy may require that all new projects be designed, tested, and maintained for Y2038 compliance if at all possible. The policy can further require that exceptions be formally documented and approved, thereby enabling them to be tracked and addressed sometime later.

Start assessing your company's level of exposure to Y2038. This should include all digital systems used or produced by your company, from the largest business system to the smallest embedded system. It should also include all databases and storage systems, third-party and developed system and application software, and any custom network protocols. When issues are found with third-party products, you should contact those vendors and request that they update their products to be compliant.

Budget for Y2038. The above actions cannot happen without a financial commitment from management. Postponing these actions also has a cost, likely much higher than you expect. The cost is not just money... it is also time (since issues will take longer to fix later) and employee satisfaction (since developers generally want to work on new things, not on date issues in old systems). Budgeting now will save money in the long run.

Mac OSes prior to 10.4 used a 32-bit unsigned integer with an epoch of Jan 1, 1904 which will rollover on Feb 6, 2040.

Mac OSes including 10.4, 10.5, and 10.6 (32-bit version) for both x86 and PPC have an issue with Y2038.

Mac OSes starting with 10.7 Mavericks (aka OSX) are 64-bit with an epoch the same as Linux/Windows (Jan 1, 1970), so OSX itself does not have a Y2038 issue.  However, note that 32-bit apps (which may have Y2038 issues) can be run in OSX. There is also no inherent guarantee that 64-bit apps are Y2038 compliant.

Like all software that uses time, OSX apps must be verified to be Y2038 compliant.

See this link for more details on Mac OS epochs.

The obvious first-order approach is to simply set the time of the system in question to a date past 2038 and see if there are issues. In some cases, this kind of 'black box' testing may work, but there are a lot of things to consider. Depending on the system, you may not be able to change the date on a live system without repercussions, so you may need to set up a sandbox in which to test. Depending on the size and complexity of the system, the time and cost to do this may be significant, but there may be no other way.

There are some commercial products available for testing future dates on Linux, Windows, and z/OS.

It totally depends on your needs. For new projects, the incremental cost of a requirement for Y2038 compliance (without using outsource staff) is probably trivial relative to the cost of the project. But if you have a significant existing portfolio of products and complex business systems, outsourcing may be a viable option to help with Y2038 assessment and/or mitigation, thus freeing up your prime in-house developers to continue working on forward looking projects instead of date/time issues.

As far as we know, z/OS does not have an inherent issue with Y2038. However, z/OS will experience a rollover of its Time Of Day clock on Sept 17, 2042. Also consider that z/OS may be interfacing with other systems which do have Y2038 issues, and there may be issues with databases, storage systems, and communication protocols to take into account.

See this link for a bit more detail.

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 the high hardware cost and limited availability. At the time, computers were extremely expensive, so limiting the representation of time to 32 bits seemed like an acceptable trade-off. 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, Linux, the IBM PC, DOS, all versions of Windows (prior to 64-bit versions), and all compilers and other tools that support these platforms.

Probably not. See this link.

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
-Firmware/BIOS
-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
-Databases
-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.

Yes. The TIMESTAMP data type has a range of 00:00:01 on Jan 1, 1970 to 03:14:07 on Jan 19, 2038 (UTC).

The DATETIME data type is a good alternative, having a range from  Jan 1, 1000 to Dec 31, 9999.

Also, the UNIX_TIMESTAMP() function returns 0 after 03:14:07 on Jan 19, 2038.

There is no universal solution to Y2038. Each development environment and programming language has unique issues and potential solutions. 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 part of the solution (if that is possible for your projects). This should provides 64-bit time functions. Existing code still needs to be checked for Y2038 issues. Y2038-compliant versions of any third-party libraries should also be used.

In some 32-bit systems, it may be possible to change the representation of time (e.g. 'time_t' in "C") from a signed integer to an unsigned integer, thus extending the time range another 68 years to 2106. Times prior to the epoch of Jan 1, 1970 would no longer be supported, but that may be an acceptable compromise. The time library for your environment would need to be replaced with one that uses 32-bit unsigned integers. All calls to existing time functions would need to be replaced with the new functions, and of course tested thoroughly.

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

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. Again similar to above, to use this approach for addressing Y2038 would require a new time-related function library to support this time format, as well as 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 interpreted to mean +/- 68 years from the actual current date.

In new hardware designs, the 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 extended time range functionality.

Part of almost any Y2038 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 should be carefully reviewed. For example, values of a 64-bit type time_t can inadvertently be cast or stored into 32-bit integers.

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 an 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 types of modifications would require changing broadly established industry standards (not to mention even more extensive coding changes), such improvements will most likely not be broadly accepted.

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.

First, note that there are options for embedded systems with 32-bit CPUs to be Y2038 compliant without resorting to 64-bit CPUs. For example, a 32-bit embedded system may be able to use a 64-bit time library, or a time library with 32-bit unsigned time_t to handle dates through 2106.

Below are some 64-bit CPUs already available. 64-bit CPUs are an area of active development, so this information may become out of date quickly.

Broadcom BCM2837 - This quad-core 64-bit SoC is based on ARM Cortex-A53 and runs at 1.2GHz. It can be used for mobile devices, but it is also intended for general purpose usage. Most notably, it is the processor used in Raspberry Pi 3 which was recently announced in Feb 2016. The Raspberry Pi 3 is very impressive, at ~10x the performance and the same cost (~$35 US) as the first Raspberry Pi (which was based on a 32-bit processor and therefore susceptible to Y2038). However, all currently available operating systems for the Raspberry Pi are 32-bit. See this link for additional discussion.

Allwinner A64 - This chip is also based on ARM Cortex-A53, with a price of around $5. It is the processor being used in the Pine64, which is also impressive, selling for as little as $15.

HiSilicon Kirin 6220 - An 8-core SoC based on ARM Cortex-A53 at 1.2GHz. Used in the HiKey dev board which sells for around $99 depending on configuration.

Qualcomm Snapdragon - The 800, 600, and 400 series Snapdragon processors are almost all capable of running in 64-bit mode. Below are several of the available development boards:

1. DragonBoard 410c from Arrow Electronics for $75
2. Open-Q 600 from Intrinsyc for $165
3. DragonBoard 810 from Intrinsyc for $495

Nvidia Tegra K1 - This processor is used on the Google Nexus 9 tablet

Nvidia Tegra X1 - This processor is used in the Google Pixel C Chromebook

MediaTek MT6752- Another processor intended for mobile devices

All of the above products are based on technology from ARM Holdings. ARM offers a variety of 64-bit designs which it licenses to other companies.

Intel offers many variations of 64-bit CPUs with "Embedded Options Available". These can be listed and compared using the selection guide/chart here.

AMD offers some 64-bit CPUs for embedded use. The Wikipedia page here has a useful table.

The Global Positioning System, or GPS uses a raw date format which consists of 13-bit 'number of weeks' field and a 'seconds into the week' field, using an epoch of Jan 6, 1980 at 00:00:00 (UTC). The 'number of weeks' field will rollover after 8192 weeks (157 years), so GPS itself should not have any date/time issues until the year 2137. However, Y2038 issues may exist if the raw dates/times from GPS are improperly translated to other date/time formats, or translated to formats such as 32-bit signed integer which inherently have Y2038 issues.

See the wiki page for GPS here for more details.

In a nutshell, the answer is yes, most mobile devices have Y2038 issues, and will continue to have such issues, likely up to and including in 2038.

Most mobile devices today are based on 32-bit technology, but there is a major shift underway in the mobile device markets to move to 64-bit technology. Some high-end devices are already using 64-bit microprocessors. Chances are good that the majority of cell phones and tablets will contain 64-bit processing chips by 2038. However, using such chips does not solve all Y2038 issues, for several reasons. First, 64-bit processing chips contain multiple cores, some of which may be 32-bits. As a result, there may be Y2038 issues in the embedded system firmware exchanging dates and times between 64-bit and 32-bit cores.

Another reason why mobile devices may have Y2038 issues in 2038 has to do with the way the fact that mobile devices require precise time synchronization with the current time and may have no easy way for developers to test their applications with future dates.

The worst-case Y2038 scenarios are roughly the same as those predicted for Y2K. In fact, the chance of catastrophic events is 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.

The absolute worst case scenario is one in which all infrastructure components simultaneously and completely stop working, including power utilities, transportation, satellites, communication, Internet, banking, commerce, medical devices, etc. Electric power plants could go off line. Nuclear power plants could experience core melt downs. Military munitions could misfire or become non-functional. Cars, planes, trains, boats, submarines, etc. may not start, fail abruptly, 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 devices with embedded computers may malfunction, including cell-phones, pace makers, ATMs, and stop-lights. Non-compliant databases could easily cause a fair amount of confusion until the problems are resolved.

Fortunately, there is still plenty of time left to address all of these potential issues so that hopefully no major catastrophes occur.

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-2038 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.

Crazy as it sounds, this question comes up a lot when discussing Y2038. There are many reasons to care about addressing Y2038. For one, your children and grandchildren will hopefully be very much alive in 2038. Also, not addressing Y2038 could literally cause catastrophes. 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 burden of addressing Y2038 (and potentially recovering from avoidable catastrophes if the issues are left unaddressed).

Our definitions are:

Y2038 compliance means that a given system will not have Y2038 issues to at least a specified date beyond 2038.

Y2038 certification means that an organization has certified that a given system will not have Y2038 issues and is certified to function without date-related issues to at least a specified date beyond 2038.

At the moment, there are no (known) official or even unofficial industry standards for Y2038 compliance/certification. It would be a positive development for such standard(s) to be created, and we at Y2038.com are interested in participating in the standard(s) development process. Let us know if you are also interested. Perhaps we can get the ball rolling through a grass-roots effort.