64-bit time

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, 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.

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 proposes a DEB_BUILD_OPTIONS=future=+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=future=+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. (We do not yet know how big that set is).

Other projects

Links to work in this area by other projects

Choices

We can 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. However so far there has been very little interest in a new triplet from other distros, and research to date has suggested that a standard transition may be feasible.

Strictly speaking a new ABI should mean a new triplet, but it's not that simple as in fact we do ABI-changing migrations within an existing triplet all the time (most SONAME changes). And sometimes larger ones like LFS and libc5->libc6. So treating this as just another migration also makes sense.

If Debian used a new triplet for the new ABI, but all the rest of the Linux world migrated the ABI within the existing triplet it would become very unclear what the existing 'arm-linux-gnueabihf' triplet means. It's quite important that there is cross-distro agreement about the way forward here. Plans are being discussed, and you should join the distributions@lists.linux.dev list if you are interested.

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).

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.

Current status

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.

Are there any problems with non-C language families Java, Python, Perl, Go, Ruby, Haskell, Rust etc? How do those treat time_t and what do they expose in inter-package communications?

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 most of the things in the 2nd class.

Known Issues

Bug tracking

Please tag all 64-bit-time bugs 'time64' (user=debian-devel@lists.debian.org, tag=time64) 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-devel@lists.debian.org' --pseudo-header 'Usertag: time64' --no-tags-menu --severity normal --body-file $template

or to tag an existing bug 

bts user debian-devel@lists.debian.org , usertags 12345 time64

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. We should prepare a plan during the Bookworm freeze and execute it during 2023.

  1. Make a complete list of libraries with changed public ABI changes that must transition together.
  2. Collect list of issues/tests - determine associated risks.
  3. Agree plan of action

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: