FAQ Categories: Developers

Detailed Y2038 information for developers

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.

What 64-bit CPUs are available for embedded systems?

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.

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.

Is IBM z/OS Y2038 compliant?

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.

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.

Is Perl Y2038 compliant?

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.

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

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.