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.
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).
Links to work in this area by other projects
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 email@example.com 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.
- The implications of a transition are being studied. The library transition appears to involve about 113 packages, which is a lot, but probably manageable
Packages building with gnulib will automatically get 64-bit time_t if glibc >=3.34 is present, unless the macro gl_cv_type_time_t_bits_macro is set to stop it.
How to help
Build your package with DEB_BUILD_OPTIONS=future=+lfs and _FILE_OFFSET_BITS=64 and _TIME_BITS=64 set and test it.
- Check especially if on-disk files/formats are affected or if there are any ABI/API changes your package exposes.
- Don't upload your package with these options enabled until any libraries you depend on have been uploaded.
- Record explicit tests for potential transition bugs on this page.
- Report bug on packages that have issues, with tag 'time64'.
- Fix bugs tagged 'time64'.
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:
- Things that break in 2023 due to the transition to 64-bit time.
- 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.
- NFSv3 (uses 32-bit time). Some client may use an unsigned int so have another 70 years?
INN has time_t embedded in the disk format.
- cpio - does it use signed int (31 bits) or 33-bit time (11 octal digits)? - different info.
- 32-bit wine (i386 only). Does it still work with 64-bit time?
Please tag all 64-bit-time bugs 'time64' (firstname.lastname@example.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: email@example.com' --pseudo-header 'Usertag: time64' --no-tags-menu --severity normal --body-file $template
or to tag an existing bug
bts user firstname.lastname@example.org , usertags 12345 time64
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.
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.
- Make a complete list of libraries with changed public ABI changes that must transition together.
- Collect list of issues/tests - determine associated risks.
- Agree plan of action
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:
- Of 767 library packages: 209 analyser failed, 558 checked
- 82 changed ABI, 476 did not. (17%) (Ubuntu tests)
- So maybe 113 libs in transition
The Debian analysis looks like this so far:
- Total *-dev packages: 10323
- 4963 are golang-*, librust-* and libghc-* which we can ignore, leaving 5360 packages
- 5237 packages have a .so in them to check
329 changed ABI due to time_t, 58 changed ABI due to enabling LFS, making 387 (7%)
1840 did not change ABI (34%)
1637 failed to run the abi-compliance-checker (31%)
- implies 400-500 packages in the transition