64-bit time

Contents

  1. 64-bit time
    1. Current Status
      1. Affected packages
    2. Goal description
    3. Background
      1. Other projects
      2. Choices
      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 started on 27th Feb 2024.

Notes about bootstrapping architectures, work arounds, current status: 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 int rolls over (potentially setting time back to 1900). Good technical details are given on this glibc page, and a very general overview at https://theyear2038problem.com/

This FOSDEM talk (PDF) also gives a good overview of the status as of Feb 2023

This is now less that 15 years away and plenty of system 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 still shipping new devices (automotive, IOT, TVs, routers, plant control, building monitoring/control, cheap Android phones). Some of that hardware will probably be running Debian or its derivatives. Other binary distros are dropping 32-bit support (RedHat/Fedora have already done so, SUSE's support is unofficial), so what is left is more likely to end up in the Debian ecosystem. Most such new hardware will be running build-from-source OSes like OpenEmbedded, or 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 for long enough to hit Jan 2038.

Debian is primarily concerned about the armhf architecture as the one 32-bit architecture most likely to still be getting significant usage in new systems over the next decade. But i386, armel, mipsel (and 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. 6429 of Debian's 35960 packages have time_t in the source. Packages which expose structs in their ABI which contain time_t will change their ABI. 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 use of the new API/ABI - each build/package chooses explicitly to use the 64bit API/ABI (by setting _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'. 1030159 has implemented a DEB_BUILD_OPTIONS=abi=+time64 option as a consistent Debian mechanism.

This transition is similar to the LFS (Large Filesystem Support) transition, where glibc also provided both 32-bit and 64-bit APIs and using the 64-bit ABI (by setting _FILE_OFFSET_BITS=64 (or DEB_BUILD_OPTIONS=abi=+lfs 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 arch 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 (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.

So, in summary:

Transition in place

We have done large ABI break transitions before such as libc5 -> libc6 ('g' suffix - which still remains today in libpam0g and zlib1g!), and GCC 4.0 C++ ABI ('c2' suffix). However those affected all architectures, not just old 32 bits 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, s390 (2007) ('ldbl' suffix).

A large in-place transition will affect all of Debian, but only benefit the remaining 32-bit arches, so we do need to try and do this reasonably efficiently in order not to hold things up for too long. Fallout from breakage should fall almost entirely on the 32-bit arches 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 so far been found.

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

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

So far as I can determine most language runtimes do not appear to have problems here except insofar as they have C-library interfaces. Those issues resolve to the known C/C++ ABI issue.

Another source of issue is packages that fails building with the time64 build flags on. The flags can be turned on with:

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.

Note that there are two classes of breakage:

  1. Things that break in 2023 due to the transition to 64-bit time.
  2. Things that break in 2038 due to the date actually wrapping.

We only need to worry about the 1st of those for the transition itself. And that transition should fix quite a lot of the things in the 2nd class.

Known Issues

Bug tracking

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

Here is an example (assuming you have a patch file, and a body template file) 

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

or to tag an existing bug 

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

Tests

Please list explicit tests for things you think might break. Assume the people working on this transition know nothing of your software. They will be very grateful for commands/tests they can run (and 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 2023 https://lists.debian.org/debian-devel/2023/05/msg00168.html to do a transition early in the Trixie cycle. We hope this will occur in jan 2024.

  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 arches except i386 and hurd-i386 (filter this out for 100-odd 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 5000-6000 packages which depend on those. By the magic of transitions this just works.

ABI transition

Packages which expose structs in their ABI which contain time_t will change their ABI. We are analysing the set of packages involved, and initial investigations (in Ubuntu) produced the following:

The Debian analysis looks like this so far: