The Unix year 2038 problem

Eight years ago, the Y2K bug came and went without many problems. Despite predictions of widespread failure, crisis was averted by both long-term and last-minute planning and intervention, and no critical systems failed. In the years since, those few operating systems and applications that were affected have in most cases been upgraded, replaced or retired.

If you use a Unix- or Linux-based system, there's one more date-related bug you'll need to worry about -- 30 years from now.

All 32-bit Unix/Linux-based systems store the system clock time internally as the number of seconds since the Epoch, or 00:00:00 on January 1, 1970. This internal data type, time_t, is in most cases a 32-bit (4-byte) signed integer. If the system in question follows the POSIX standard (as most Unix and Linux systems do), the latest time and date that can be represented as seconds-since-the-Epoch in that 32-bit signed integer is 3:14:07 UTC on Tuesday, January 19, 2038.

After this time and date, the internal representation of the system time will reach 2147483647, the highest number storable in a 32-bit signed integer. One second after that, it will wrap around to a negative number, -2147483648. Current applications will either interpret this negative number as an older year (1901) or freeze the system clock at 03:14:07 on 1/19/2038. This will possibly cause applications and operating systems to fail, as they are not designed to work with a hung system clock or one showing the

    Requires Free Membership to View

year as 1901.

There are no viable fixes (that do not break existing applications) for systems using 32-bit processors, or operating systems and applications running in 32-bit mode on 64-bit processors. Many current Unix/Linux operating systems already run in 64-bit mode (with a corresponding "long" time_t when on a 64-bit processor; in most cases this solves the problem.

Operating systems that support a long 64-bit time_t are most likely not affected by the Year 2038 bug in terms of the internal system clock. However, applications that use a 32-bit time_t can still fail, even if the system running the application supports full 64-bit operation.

Here's a quick overview of the current status of Year 2038 support in mainstream Unix/Linux releases:

  • Solaris 7 or higher on 64-bit UltraSPARC and SPARC64 processors, as well as Solaris 10 on x86-64 platforms, has a 64-bit time_t.

  • AIX Version 4.3.3 on 64-bit PowerPC and Power processors has a 64-bit time_t.

  • The Linux kernel running in 64-bit mode on IA64 or x86-64 processors has a 64-bit time_t.

  • Mac OS X Version 10.4 and newer has a 32-bit kernel, but applications can use a 64-bit time_t when running on PowerPC G5 or x86-64 CPUs.

  • FreeBSD 6.0 and higher has a 64-bit time_t when running on a 64-bit platform.

  • OpenBSD 4.1 and newer support a 64-bit time_t.

  • NetBSD does not yet have a 64-bit time_t, but efforts are underway to fix the problem for an upcoming release.

Even if your current operating system is not yet 2038 safe, don't worry! People have been aware of the issue for many years now, and are actively working on solutions. In most cases, the problem will be solved by having the operating system and applications eventually run in full 64-bit mode.

I expect all major desktop operating systems to be fully 64-bit in the next five to 10 years. Additionally, a trickle down effect will help to replace current systems with 64-bit configurations where it is applicable and cost effective.

ABOUT THE AUTHOR: Bill Bradford is the creator and maintainer of SunHELP and lives in Houston, Texas, with his wife Amy.

This was first published in May 2008

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.