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.

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.

When should my company start preparing for Y2038?

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.

What will happen to after 2038?

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

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

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

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

For future date testing purposes, there are some tools available for DTS (Date/Time Simulation) for platforms including Windows, Linux, and z/OS.

There are presently no known code scanning tools specifically for Y2038, but based on the sheer magnitude of Y2038, such tools will undoubtedly become available. We plan to review as many Y2038-related products as possible and keep an up to date list with reviews here.

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.