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.

Should I use outsourcing to address Y2038?

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 an executive, what actions should I take now?

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.

What does “Y2038 compliance” and “Y2038 certification” mean? Is there an official standard for this?

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

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.