The perils of transition to 64-bit time_t

Original Article ↗ Hacker News Discussion ↗

Gentoo vs. other distros (binary, NixOS, etc.)

  • Source-based distros like Gentoo struggle because upgrades are incremental: libraries get rebuilt and installed one by one, so the system can be in a “half-32-bit, half-64-bit” ABI state where core tools no longer work.
  • Users describe workarounds: dual-root partitions, boot-environment–style approaches, chrooting into a freshly unpacked stage3, or using Gentoo’s ROOT variable to build an entire new userland elsewhere and then swap it in.
  • Some note this ignores user-local binaries (virtualenvs, cargo builds, etc.) and accumulated config/symlink cruft, so “just reinstall” is not truly trivial.
  • NixOS is cited as an example of a source-based system that avoids this by building everything in isolated stores and allowing multiple glibc versions; Gentoo lacks such atomic build/install tooling.
  • Debian and other binary distros have already switched but report that it was still painful; being binary does not magically remove the complexity.

ABI, typedefs, and multi-ABI ideas

  • time_t/off_t typedefs help source portability but not binary compatibility: once structs, function signatures, or protocols embed them, changing size breaks ABI.
  • The core problem: you must rebuild all code that uses the type in one go, or carefully support dual ABIs.
  • Various proposals are discussed: fat binaries, LFS-style dual symbol sets, linker version scripts, or library-specific “time64” variants, but these are considered a lot of work and hard to retrofit widely.
  • Some argue libc should have offered better multi-ABI mechanisms; others suggest Gentoo’s design (install-while-building) needs rethinking.

Unsigned 32-bit time_t as a stopgap

  • One camp suggests changing 32‑bit time_t to unsigned to push the failure from 2038 to 2106, easing migration.
  • Critics note loss of pre‑1970 representation, breaking subtraction and negative intervals, and silent “teleporting” of historic timestamps into the future.
  • Supporters counter that negative or pre‑epoch timestamps are rare on such systems and that upgrading signed→unsigned is easier than 32→64 bits.

Other 32-bit “bombs” and related issues

  • IPv4 exhaustion is mentioned but seen as a long, gradual squeeze rather than a hard bomb, with IPv6 as relief.
  • Filesystems: ext* and inode limits (32‑bit inode numbers) can also bite; newer filesystems use 64‑bit inodes, but compatibility issues exist with 32‑bit apps.
  • off_t/large-file support had similar ABI issues, but less pervasive than time_t.

Static vs shared linking

  • One suggestion: build all new 64‑bit‑time binaries statically to avoid ABI mixing.
  • Pushback: static linking explodes update sizes, RAM/disk usage, and rebuild cost, especially for large libraries (GUI toolkits, Chromium-like stacks) and embedded 32‑bit systems.

Broader OS experience and design reflections

  • Some OSes (FreeBSD, OpenBSD) chose 64‑bit time_t early, especially on amd64, avoiding this transition later; Linux on 32‑bit is paying that technical debt now.
  • There are calls for better ABI metadata in ELF and for clearer separation or consolidation of “stable” user/kernel boundaries via libc, but no consensus on practicality.