Debian switches to 64-bit time for everything

Original Article ↗ Hacker News Discussion ↗

Scope of Debian’s 64‑bit time change

  • Commenters note the headline overstates “everything”: Debian Trixie switches to 64‑bit time_t on all 32‑bit ports except i386.
  • i386 is being downgraded: no installer or official kernel in Trixie, mainly kept as a 32‑bit userspace on amd64 for legacy binaries. This is why it’s excluded from the time_t ABI change.
  • There is some confusion around i386 vs i686; Debian’s current “i386” is effectively i686, and a new “i686” ABI label is being introduced for 32‑bit x86 with 64‑bit time_t.

How common are 32‑bit systems?

  • Several posts argue i386 hardware is rare today; most real 32‑bit Linux devices are embedded ARM.
  • Others point to Debian’s popcon and Firefox telemetry showing a non‑trivial 32‑bit user base (often 32‑bit Windows installs, VMs, or industrial/embedded x86).
  • 32‑bit is still important in niches: running legacy games via Wine/Steam, industrial controllers, medical gear, and long‑lived embedded systems.

ABI breakage and other OSes

  • Some criticize Debian for “breaking userspace ABI” (library SONAME bumps, new package names), which complicates third‑party deb distribution.
  • Counterpoint: if old ABIs used 32‑bit time_t, an ABI break is unavoidable; changing names is the safest way to surface incompatibility.
  • BSDs moved to 64‑bit time_t on 32‑bit platforms years ago and flushed out many bugs; FreeBSD maintains compat layers.
  • Windows is mentioned as having avoided a Y2038‑style core ABI issue, but at the cost of each app largely shipping its own libraries.

Technical details: time types and filesystems

  • Discussion distinguishes the real problem (code using int instead of time_t) from the mechanical time_t size change.
  • ext4 uses split seconds/fraction fields (400‑year horizon); ZFS stores nanosecond timestamps in 64 bits (580 years), indicating 64‑bit time_t doesn’t automatically cover all on‑disk formats.
  • Some expect a long‑term move to 128‑bit timestamps (e.g., 64 bits seconds + 64 bits sub‑second), while warning about the temptation to repurpose “spare” bits.

Y2038 risk and embedded systems

  • Optimistic view: 12 years is plenty to migrate important systems; 64‑bit time support and NTP make testing post‑2038 scenarios feasible.
  • Pessimistic view: many embedded/industrial/medical devices deployed today run very old kernels and will still be in service in 2038 with unfixed 32‑bit time, potentially making Y2038 worse than Y2K.

Side threads

  • Lengthy digression on ARG_MAX/command‑line length limits: many practical pain points (linkers, tar, globs); numerous workarounds (xargs, find -exec +, response files, kernel rebuilds), with debate over whether fixed limits are prudent or archaic.
  • Re‑litigation of Y2K: defense of 2‑digit years given historic storage costs and COBOL/BCD constraints; mention of the “preparedness paradox” and UI‑level date bugs.