Does my mobile device have Y2038 issues?

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.

Does the Global Positioning System (GPS) have Y2038 issues?

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.

Do MySQL and MariaDB have Y2038 issues?

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.

Do Macs have Y2038 issues?

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.

Is Java Y2038 compliant?

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.

I’m a tester. How do i go about testing for Y2038?

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.

What is Y2038 (the more detailed version)?

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.