Are you prepared for the Unix 2038 problem?

In 2000, 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 -- in the year 2038.

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