64-bit time

Contents

  1. 64-bit time
    1. Current Status
      1. Affected packages
    2. Goal description
    3. Background
      1. Other projects
      2. Choices
        1. New triplet
        2. ABI transition
      3. Decision
      4. Transition in-place
    4. How to help
    5. Issues
      1. Known Issues
        1. Bug tracking
      2. Tests
    6. Milestones
    7. ABI transition

Current Status

The t64 transition is settled by June 2024 (no official announcement was made).

If any of your packages are not upgraded to the latest version on your Debian Testing or Debian Unstable/Sid system, now it is the time to sort it out manually.

The transition coordination occurred on #debian-devel IRC.

The actual transition began on February 27th, 2024. (See 64-bit time_t transition in progress in unstable on debian-devel-announce from February 26th, 2024)

Notes about bootstrapping architectures, workarounds and status updates is available on BrainDumpT64.

Affected packages

Goal description

Use 64-bit time_t on 32-bit architectures to avoid the "year 2038 problem" when the existing 32-bit signed integer rolls over (potentially setting time back to 1900). Good technical details are given on the Y2038 Proofness Design page on glibc wiki, with a more concise treatment available on English Wikipedia and a very general overview at theyear2038problem.com.

The Fixing Year 2038 (video) by Wookey at FOSDEM '23 (PDF) also gives a good overview of the status quo at that time.

As of 2025, this is less that 13 years away, and plenty of systems that will have problems have already been shipped; we should stop adding to the problem. Most computing, especially computing using Debian or its derivatives, is now done on 64-bit hardware where this issue does not arise. However, there is quite a lot of cost-sensitive 32-bit computing still out there and new devices are still being shipped (automotive, IoT, TVs, routers, plant control, building monitoring/control, cheap Android phones, etc.), with some of that hardware probably running Debian or its derivatives. Other binary distributions are dropping 32-bit support (Redhat/Fedora have already done so, and SUSE's support is unofficial), so what is left is even more likely to end up in the Debian ecosystem as a result. Most of this new hardware will be running build-from-source OSes like OpenEmbedded, Alpine, Android or Gentoo, but the Debian-based niche is likely to remain for some years, and some stuff built with it is likely to be in use/installed long enough to reach January 2038.

Debian is primarily concerned about the armhf architecture, as it's the 32-bit architecture most likely to still be getting significant usage in new systems over the next decade. But i386, armel, mipsel (and the hppa, hurd-i386, powerpc, m68k and sh4 ports) are also affected. Other 32-bit architectures already use 64-bit time: x32, riscv32, arc and loong32.

64-bit architectures are not affected by the Y2k38 problem, but they are affected by this transition.

Because you have to have LFS if you have 64-bit time_t (glibc enforces this), this goal is a superset of ReleaseGoals/LFS.

Background

time_t appears all over the place. 6,429 of Debian's 35,960 packages have time_t in the source. Packages which expose structs in their ABI which contain time_t will change their ABI and all such libraries need to migrate together, as is the case for any library ABI change.

glibc 2.34 provides support for both the existing 32-bit ABI/API and a new 64-bit ABI/API. However, it does not provide a switch forcing the use of the new API/ABI - each build/package chooses explicitly to use the 64-bit API/ABI (by setting -D_TIME_BITS=64). This is a problem for Debian as in a normal transition we expect that simply building against the new library will get you the new ABI. Something (glibc, dpkg, GCC?) has to say 'Use 64-bit time by default.' Bug #1030159 has implemented an abi=+time64 option for DEB_BUILD_OPTIONS/DEB_BUILD_MAINT_OPTIONS as a consistent mechanism for Debian and its derivatives.

This transition is similar to the Large Filesystem Support (LFS) transition, where glibc also provided both 32-bit and 64-bit APIs and using the 64-bit ABI by setting -D_FILE_OFFSET_BITS=64 (alternatively abi=+lfs or its predecessor future=+lfs in DEB_BUILD_OPTIONS/DEB_BUILD_MAINT_OPTIONS, which does the same thing) changes the ABI. And just to add to the fun, if you set 64-bit time then glibc enforces 64-bit file offsets, so software that has not dealt with support for LFS will also have to fix that in order to move to 64-bit time. (There are about 75 libraries that change ABI for LFS, but not time_t.)

Other projects

Links to work in this area by other projects:

Choices

We could either transition the ABI within the existing architecture(s), or we can bootstrap a new architecture (with a new triplet and ABI). Initial thoughts were that it was highly uncertain that a transition in-place was feasible because too much stuff would break, and thus a new architecture was simpler, safer and easier.

New triplet

ABI transition

We also need to choose whether to do this for all our 32-bit architectures or not. For example, one could decide that x32 fulfills the '32-bit x64 with 64-bit time' role and i386 should remain with 32-bit time for compatibility reasons (i.e. the ability to run ancient x86 binaries, especially proprietary ones that cannot be updated).

Decision

After a long discussion (mostly about i386), it was decided to do an in-architecture ABI transition for all 32-bit architectures except i386 and hurd-i386.

The i386 port will be left with the existing 32-bit time_t as a compatibility architecture for existing x86 binaries. A new 'i686' x86 ABI/architecture using 64-bit time, and potentially newer ISA features could be created, if there was sufficient enthusiasm for dragging 32-bit x86 into its now-very-limited future. The hurd-i386 port is not going to be switched as its kernel lacks support, and efforts are underway instead to switch to hurd-amd64.

In summary:

Transition in-place

We have done large ABI-breaking transitions before, such as libc5 -> libc6 (resulting in the 'g' package suffix, which still remains today in libpam0g and zlib1g!), and the GCC 4.0 C++ ABI (and corresponding 'c2' package suffix). However, those affected all architectures and not just old 32-bit ones. We have also done transitions which only affected 'minor' architectures, such as the long double migration from 64-bit to 128-bit on alpha, powerpc, sparc and s390 (2007) (creating the 'ldbl' package suffix).

A large in-place transition will affect all of Debian, but only benefit the remaining 32-bit architectures, so we do need to try to do this with reasonable efficiency in order to not hold things up for too long. Fallout from breakage should fall almost entirely on the 32-bit architectures that are changing ABIs.

How to help

Issues

People are rightly worried about stuff that will break when time_t is changed for some, but not all, of the packages on a running system. However, not that many things which will actually break have thus far been found.

Because some 32-bit architectures have been using 64-bit time for some years and x86 already went through the 32 -> 64-bit transition, things like file formats have generally been made interoperable and quite a lot of other problems have already been dealt with.

The largest area of uncertainty is regarding possible issues with changing file formats, database structures and data passed between programs over IPC mechanisms.

As far as can be determined, most language runtimes do not appear to have problems with any of this, except insofar as they have C library interfaces. Those issues resolve to the known C/C++ ABI issue.

Another source of issues are packages that fail to build with the time64 build flags on. The flags can be turned on for any debhelper-enabled package build using: 

DEB_BUILD_MAINT_OPTIONS="abi=+time64" dpkg-buildpackage

…and explicitly turned off with: 

DEB_BUILD_MAINT_OPTIONS="abi=-time64" dpkg-buildpackage

Please update this section if you know of any related issues.

Remember that there are, in fact, two distinct classes of breakage:

  1. Things that break in 2024 due to the build changes from transitioning to 64-bit time.
  2. Things that will break in 2038 due to the date actually wrapping.

We only need to worry about the first of those for the transition itself, and if the fates are kind, the transition should fix quite a lot of the things in the second class.

Known Issues

Bug tracking

Please tag all 64-bit-time bugs with the 'time-t' tag (user=debian-arm@lists.debian.org, tag=time-t) in the BTS (see usertags for instructions).

Here is an example of doing so using reportbug(1) (assuming you have a patch file, and a body template file): 

reportbug $package --src --no-tags-menu --severity normal --tag patch --body-file $template -V $version -A $patchfile \
  --subject 'Use 64bit time_t' --pseudo-header 'User: debian-arm@lists.debian.org' --pseudo-header 'Usertag: time-t'

…or to tag an existing bug, use bts(1): 

bts user debian-arm@lists.debian.org , usertags 12345 time-t

Tests

Please list explicit tests for things you think might break, assuming the people working on this transition know nothing about your software. They will be very grateful for commands/tests they can run (and their expected results) to see if things are working correctly.

Milestones

We are already late with this transition and upstreams are already moving, so doing something has become quite urgent. A plan was proposed in May 16th, 2023, (see 64-bit time_t transition for 32-bit archs: a proposal on debian-devel) to do a transition early in the Trixie cycle. We hope this will occur in January 2024.

Proposed plan of attack:

  1. Make a complete list of libraries with changed public ABI changes that must transition together.

  2. Change gcc-* to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 by default.

  3. Change dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 on all 32-bit architectures except i386 and hurd-i386 (filter this out for ~100 packages which are sensitive to LFS but not time_t).

  4. NMU all libraries with binaries renamed from libfoo to libfoot64, removing old suffixes (c102, c2, ldbl, g…) if present, and emit a Provides/Replaces/Breaks libfoo on 64-bit arches + i386 and hurd-i386.
  5. Do unchanged source rebuilds (binNMUs on all architectures) of 5,000–6,000 packages which depend on them; by the magic of transitions this "just works™."

ABI transition

Packages which expose structs containing time_t in their ABI will have breaking changes to it. We are analysing the set of packages involved, and initial investigations (in Ubuntu) produced the following:

The Debian analysis looks like this so far:

This implies 400–500 packages in the transition.

CategoryPermalink: mentioned in the Release notes for trixie