BSD and Commercial Unix

In brief: The BSD family fixed 2038 earliest. NetBSD switched to 64-bit time on every platform in 2012, and OpenBSD followed in 2014. FreeBSD used 64-bit time everywhere except old 32-bit PCs (i386), which it retired in 2025. Commercial Unix systems such as Solaris, AIX and HP-UX are safe for 64-bit programs, but many still run 32-bit programs that will break in 2038, and several of these platforms are at or near end of life.

Overview

The BSDs build the kernel and the whole base userland from one source tree. That made it practical to change time_t in one coordinated step, which Linux could not do ^[1]. The two projects took different approaches:

• NetBSD used symbol versioning (renamed __time50-style entry points) and kept a compatibility layer, so old binaries still run. Those old binaries keep their 32-bit time ^[2][3].
• OpenBSD made "one huge, incompatible ABI change". Binaries built before the change generally do not run on newer kernels, and no compatibility layer is provided ^[1].

Commercial Unix vendors moved to LP64 (64-bit long and therefore 64-bit time_t) in the late 1990s for 64-bit applications. They kept ILP32 (32-bit time_t) for 32-bit applications, for compatibility. The remaining exposure on these systems is the 32-bit software still running on them.

Technical details

OpenBSD

• OpenBSD 5.5, released 2014-05-01: "time_t is now 64 bits on all platforms." The tree "has been carefully and comprehensively audited to support 64-bit time_t". "From OpenBSD 5.5 onwards, OpenBSD is year 2038 ready and will run well beyond Tue Jan 19 03:14:07 2038 UTC." ^[4]
• Parts that could not take 64 bits were switched to unsigned 32-bit, "so they are good till the year 2106" ^[4].
• Philip Guenther committed the core change on 2013-08-12. It also widened ino_t and clock_t ^[1].
• No binary compatibility with pre-5.5 binaries ^[1]. Some software assumed time_t was a long (for example printf("%ld", t)), and early snapshots showed timestamp bugs in ports such as svlogd ^[5].

NetBSD

• NetBSD 6.0 (released October 2012): "time_t is now a 64-bit quantity on all NetBSD ports. This means that the NetBSD world no longer ends in 2037." ^[2]
• NetBSD's roadmap records that the change was completed in 5.99.7, "with no libc major bump" ^[3]. Versioned symbols let older 32-bit-time binaries keep running through the compat layer, but those binaries still have the 2038 problem ^[6].

FreeBSD

• FreeBSD uses a 64-bit time_t on every architecture except i386. The arch(7) manual page states: "time_t is 8 bytes on all supported architectures except i386." ^[7] Notably, 32-bit armv7 and 32-bit powerpc ports were given a 64-bit time_t, and only i386 kept 32 bits for ABI compatibility.
• FreeBSD's own bug tracker notes that "FreeBSD/i386 still has a 32-bit time_t". Ports such as GNU tar need --disable-year2038 to build there ^[8].
• Deprecation of i386: In early 2024 the project announced that FreeBSD 15.0 would drop armv6, i386 and 32-bit powerpc, and that 16.0 would drop armv7. Running 32-bit binaries on 64-bit kernels would be supported through at least stable/16 ^[9][10].
• FreeBSD 15.0-RELEASE (late 2025): "The venerable 32-bit hardware platforms i386, armv6, and 32-bit powerpc have been retired … The armv7 platform remains as the last supported 32-bit platform." The UFS1 date limit was moved from 2038 to 2106 ^[11].
• Residual risk: FreeBSD 13.x and 14.x i386 installations, and i386 binaries run under COMPAT_FREEBSD32 on amd64, still use a 32-bit time_t.

illumos (OpenIndiana, SmartOS, OmniOS) and Oracle Solaris

• 64-bit Solaris and illumos programs (LP64) have a 64-bit time_t. 32-bit programs (ILP32) have a 32-bit time_t.
• illumos IPD 14 "illumos and Y2038" (status: predraft) states the problem plainly. illumos has dropped 32-bit kernels, but 32-bit userland is still supported and about 90% of utilities are built only as 32-bit. "The basic plan is to simply rebuild all libraries and utilities as 64-bit." IPD 14 also lists UFS timestamps, utmp/wtmp/lastlog, uniqtime32(), ZFS time clamping, Kerberos and BPF's bpf_timeval as areas to fix ^[12].
• SmartOS tracks the work as OS-8097, "64-bit userspace for SmartOS". It was still in progress at the last check ^[13].
• Oracle Solaris 11.4 converted most of its userland to LP64. Oracle documented this in a blog series on the "LP64 conversion" ^[13]. IPD 14 notes that Oracle Solaris offers a utime32_t with an unsigned range as a guard rail to 2106 ^[12]. A post on the tz mailing list notes that 32-bit Solaris applications, even running on current Solaris, would stop working in 2038 ^[14]. That is a community statement, not an Oracle one.

IBM AIX

• AIX 5L and later run 64-bit kernels on POWER. 64-bit applications have a 64-bit time_t. 32-bit applications, which are still widely deployed, have a 32-bit time_t (no IBM AIX-wide y2038 statement found as of 2026-10-21).
• IBM has fixed individual AIX components. APARs IV92515 and IV92528 corrected /usr/bin/istat and the JFS2 istat helper, which "couldn't handle dates past the 2038 rollover". IBM also notes that JFS (JFS1) has a 32-bit timestamp design limitation that cannot be changed ^[15].
• On IBM z/OS (not AIX), Language Environment gained support for 31-bit clock values beyond 2038 starting with z/OS V2R3 ^[15].

HP-UX

• HP-UX documentation, as quoted by HPE community members, states that dates past 2038 "cannot be represented in the time_t data type in 32-bit HP-UX", while 64-bit HP-UX handles dates up to 9999 ^[16].
• End of life: HP-UX 11i v3's final release was 2505.11iv3 (2025-05-22). Standard support for Integrity servers ended on 2025-12-31, with "Mature Software Product Support without Sustaining Engineering" through at least 2028-12-31. HP 9000 (PA-RISC) support ended earlier ^[17]. Every HP-UX system still running in 2038 will be far outside vendor support.

Other legacy commercial Unix

Tru64, IRIX, SCO OpenServer/UnixWare and older Solaris releases (≤ 10 on 32-bit SPARC/x86) are out of support. Any surviving installation should be treated as not 2038-safe unless proven otherwise by testing. OpenVMS (not Unix) moved its C runtime to an unsigned 32-bit time_t in 1998, which extends it to 2106 ^[6].

Affected versions / products

Risk & compliance notes

• Commercial Unix systems hold the critical old workloads. These are banking, telecom and ERP systems running 32-bit binaries whose source may be lost. Inventory with file(1), elfdump or dump -X32 and similar tools.
• Vendor EOL comes before 2038. HP-UX is already past standard support. Plan migrations, not patches.
• On-disk formats (UFS1, JFS1, utmpx) can limit dates even when every binary is 64-bit. See File-Systems.

Detection & mitigation

• Identify 32-bit executables. On Solaris/illumos use file /usr/bin/* | grep 32-bit. On AIX use file or dump -ov. On HP-UX, file reports ELF-32.
• Rebuild applications as 64-bit (-m64 with gcc/clang, -q64 with IBM XL C on AIX, +DD64 with HP aCC).
• Test with the system clock set past 2038 in an isolated partition, zone or LPAR.
• See Testing-and-Detection and Remediation-Guide.

See also

• Year-2038-Problem · Operating-Systems · OS-Linux · OS-macOS-and-iOS
• File-Systems · Lang-C-and-CPP · Year-2106-and-Beyond
• Risk-Assessment-Checklist

References

1. Pondering 2038 — LWN.net (Jonathan Corbet), 2013-08-14. OpenBSD's 2013 commit and its "one huge, incompatible ABI change".
2. Announcing NetBSD 6.0 — The NetBSD Project, 2012. 64-bit time_t on all ports.
3. NetBSD system roadmap (doc/roadmaps/system r1.10) — NetBSD, 2012-01. Completed in 5.99.7 with no libc major bump (seen in search results).
4. OpenBSD 5.5 — OpenBSD, released 2014-05-01. Release notes quoted above.
5. svlogd timestamps fail on OpenBSD 5.5 (snapshot) — supervision mailing list. An example of porting fallout (seen in search results).
6. Year 2038 problem — Wikipedia. Secondary source: NetBSD compat binaries still affected; OpenVMS unsigned time_t since 1998.
7. arch(7) — FreeBSD Manual Pages. time_t is 8 bytes everywhere except i386.
8. FreeBSD Bugzilla #272622 — FreeBSD. "FreeBSD/i386 still has a 32-bit time_t" (gtar --disable-year2038).
9. FreeBSD phasing out 32-bit platforms — LWN.net, 2024. The 2024 deprecation plan (seen in search results).
10. FreeBSD Continues Push Toward Deprecating 32-bit Platforms — Phoronix. Plan details and 32-bit compat through stable/16 (seen in search results).
11. FreeBSD 15.0-RELEASE Release Notes — FreeBSD Project. i386, armv6 and powerpc retired; UFS1 limit deferred to 2106.
12. IPD 14: illumos and Y2038 — illumos Project Discussions (GitHub). ~90% of utilities 32-bit; plan to rebuild as 64-bit.
13. OS-8097: 64-bit userspace for SmartOS — SmartOS bug tracker. Links to the Oracle blog "Oracle Solaris 11.4 beta: progress on LP64 conversion", which returned HTTP 403 when fetched.
14. tz mailing list message on Solaris 32-bit applications and 2038 — IANA tz list, 2022. A community statement (seen in search results).
15. IBM APAR IV92515 — IBM Support. The istat 2038 fix and the JFS 32-bit timestamp limitation (seen in search results). z/OS context from Longpela Expertise.
16. HPE Community: how to set date beyond 31st Dec 2037 — HPE Community and the 32-bit getdate thread. These quote HP-UX getdate documentation (seen in search results).
17. The last supported version of HP-UX is no more — The Register, 2026-01-05. End of standard support 2025-12-31; mature support to 2028 (seen in search results).