long story short:

“The Year 2038 problem is where the Unix time can no longer be stored in a signed 32-bit integer and thus after 19 January 2038 will begin wrapping around as a negative number for representing the number of seconds since 1 January 1970.” (src)

Insight: Linux Kernel 5.6 To Fix the Year 2038 Issue

For now, it seems like Linux Kernel 5.6 is probably going to solve the possible year 2038 issue. Linux Kernel 5.6 is ready to deal with “Y2038” or “Unix Y2K” problem.

Linux Kernel 5.6 To Fix The Y2038 Issue

Linux developer Arnd Bergmann mentioned this feature in an email mailed to Linus Torvalds.

As a result, linux-5.6, or my backport of the patches to 5.4 [1], should
be the first release that can serve as a base for a 32-bit system designed
to run beyond year 2038, with a few remaining caveats:

  • All user space must be compiled with a 64-bit time_t, which will be supported in the coming musl-1.2 and glibc-2.32 releases, along with installed kernel headers from linux-5.6 or higher.
  • Applications that use the system call interfaces directly need to be ported to use the time64 syscalls added in linux-5.1 in place of the existing system calls.
    • This impacts most users of futex() and seccomp() as well as programming languages that have their own runtime environment not based on libc.
  • Applications that use a private copy of kernel uapi header files or their contents may need to update to the linux-5.6 version, in particular for sound/asound.h, xfs/xfs_fs.h, linux/input.h, linux/elfcore.h, linux/sockios.h, linux/timex.h and linux/can/bcm.h.
  • A few remaining interfaces cannot be changed to pass a 64-bit time_t in a compatible way, so they must be configured to use CLOCK_MONOTONIC times or (with a y2106 problem) unsigned 32-bit timestamps.
    • Most importantly this impacts all users of ‘struct input_event’.
  • All y2038 problems that are present on 64-bit machines also apply to
    32-bit machines.

    • In particular this affects file systems with on-disk timestamps using signed 32-bit seconds:
    • ext4 with ext3-style small inodes, ext2, xfs (to be fixed soon) and ufs.

src: https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/

so while ext3 is a very good (but a bit slow) filesystem if the user wants to be able to undelete files

y2038 could be the time, when ext3 is not an option anymore (maybe for data partitions it might be not a problem… not sure for /root partitions… it remains to be tested, what happens if all files on /root or /boot or /home are set to the date 1.1.1970… will the system boot or not? (it is even possible to set a creation date of 1950)

hostnamectl; # tested on 
  Operating System: Debian GNU/Linux 10 (buster)
            Kernel: Linux 4.19.0-16-amd64
      Architecture: x86-64

echo "test" > test.txt

touch -a -m -d '01/01/1970 00:00:00.000' test.txt

stat test.txt 
  File: test.txt
  Size: 5         	Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d	Inode: 394883      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 1970-01-01 00:00:00.000000000 +0100
Modify: 1970-01-01 00:00:00.000000000 +0100
Change: 2021-05-19 16:37:51.548857724 +0200
 Birth: -

in comparison to Y2K:

“The issue became when it became 2000 because that would be stored as 00 in the program.

This caused many to believe that say, bank software wouldn’t be able to get your money out because it was getting it from 1900 rather than 2000.

This involved a lot of hotfixes, resulting in millions of dollars of upgrades just to fix this bug. While some things did fail, most of the world chugged along like nothing ever happened.” (src)

… so FreeBSD almost solved this issue already – while the linux kernel is having a hard time. what about micro kernel systems like hurd?

the y2038 problem:

2015: Jonathan Corbet

There are now (in 2018) less than 20 years remaining until that fateful day in January 2038 when signed 32-bit time_t values — used to represent time values in Unix-like systems — run out of bits and overflow.

As that date approaches, 32-bit systems can be expected to fail in all kinds of entertaining ways and current LWN readers can look forward to being called out of retirement in a heroic (and lucrative) effort to stave off the approaching apocalypse.

Or that would be the case if it weren’t for a group of spoilsport developers who are trying to solve the year-2038 problem now and ruin the whole thing.” (src)

“When kernel, libraries and applications are compiled, the compiler will turn this assumption machine code and all components later have to match each other.

So a 32-Bit Linux application or library still expects the kernel to return a 32-Bit value even if the kernel is running on a 64-Bit architecture and has 32-Bit compatibility.

The same holds true for applications calling into libraries.

This is a major problem, because there will be a lot of legacy software running in 2038.” (src)

no ext2/ext3 after 2038

BTW: ext4’s 34Bits wide time-stamp will run into the same problem (out ouf time-bits in May 2446 according to this guy)

src: https://www.slideshare.net/szlin/y2038-issue

Sometimes it seems that things have gone relatively quiet on the year-2038 front.

But time keeps moving forward, and the point in early 2038 when 32-bit time_t values can no longer represent times correctly is now less than 21 years away.

That may seem like a long time, but the relatively long life cycle of many embedded systems means that some systems deployed today will still be in service when that deadline hits.

One of the developers leading the effort to address this problem is Arnd Bergmann; (operating at IBM Deutschland Böblingen (near Stuttgart)) at Linaro Connect 2017 he gave an update on where that work stands.

That work, he said, is proceeding on three separate fronts, the first of which is the kernel itself. He has been working for the last five years to try to prepare the kernel for 2038.

Much of that work involves converting 32-bit timestamps to 64-bit values, even on 32-bit systems.

Some 32-bit timestamps also show up in the user-space API, which complicates the issue considerably.

There is a plan for the enhancement of the user-space API with 2038-clean versions of the problematic system calls, but it has not yet gotten upstream.

One recent exception is the statx() system call, which was merged for 4.11; statx() will serve as the year-2038-capable version of the stat() family of calls. There are quite a few other system calls still needing 2038-clean replacements, though.

There is one other person, Deepa Dinamani, working on the kernel side of things; she started as an Outreachy intern and has continued to work on the problem after the internship ended.


Dinamani has a set of virtual filesystem layer patches in hand, which address one of the hardest [Arnd Bergmann] problems, and she has plans for some other system calls as well. One of the trickier ones might be setsockopt(), which isn’t easily fixed or emulated at the glibc level.

There are device-mapper and input subsystem patches in an advanced state.

Bergmann had a patch for the video4linux subsystem, but that was rejected and needs a new approach; a similar situation exists for the audio subsystem.

Other areas needing work in the kernel are key management and realtime clocks.

For some system calls, there will be no replacement, since the best approach appears to be emulation in the C libraries — the second focus for the year-2038 effort.

There has been a lot of work done in the glibc community in particular, he said; the plan is to be fully backward compatible at that level.

That means that it will be possible to build a program with either 32-bit or 64-bit timestamps, and to use the larger timestamps even on older kernels.

In other words, the glibc developers are trying to make things work everywhere, with a minimum of disruption.

(See this draft design document for lots of details on the glibc plan.)

The third focus is on distribution builds, which can only really proceed once the first two pieces are in place. Most distributors, Bergmann said, are unlikely to even bother with 32-bit systems in 2038, so they won’t have much to worry about. One big exception may be Debian, which seems interested in maintaining support, even though it looks like it will be a painful task. It may require a full rebuild at some point, which isn’t much fun for anybody involved, but it is at least a process that is known to work. Compatibility is key in such a system; there is code being deployed now that may not be 2038-clean, but people want it to keep working if at all possible.

One big area of concern is automobiles. A lot of devices, such as handsets, will have long since failed for any of a number of other reasons by then, so there is little point in ensuring that they can survive 2038.

But people keep cars going for a long time.

There may still be cameras in use by then, and there is highly likely to be a lot of deeply embedded systems such as building infrastructure.

Some of these systems are going to fail in 2038.

That is why it is important to get the problem fixed as soon as possible.

There are some things that are going to be difficult to fix, though, even when the kernel, C libraries, and distributions are mostly taken care of; many of these are the result of the use of 32-bit time_t values in file formats. Thus, for example, cpio will fail, which is problematic because it is used by the RPM package format. The NFSv3, ext3, and XFS filesystems all have problems resulting from their use of 32-bit timestamps. The first two are likely to have gone out of use long before the problem hits, and plans for the repair of XFS are in the works. Then, of course, there is a whole list of applications that nobody has yet noticed are broken, and lots of in-house applications that cannot be fixed by the community.

When asked which tools he is using for this work, Bergmann replied that his core technique involves building kernels with the 32-bit time types removed completely. That will quickly point out the places that still need to be fixed. Beyond that, he said, it’s mostly a manual process. It was suggested that sparse or GCC plugins could maybe help with this task.

As things wound down, John Stultz asked how much the work in the BSD camp, which has (in some variants) already solved its year-2038 problems, might help with Linux. The answer would appear to be “not much”. BSD-based distributions have the advantage of being able to rebuild everything from scratch, so they do not need to maintain user-space ABI compatibility in the same way. There is some value in in the work that has been done to fix applications with year-2038 problems, but it’s not clear how much that will help the Linux community.

[Thanks to Linaro and the Linux Foundation for funding your editor’s travel to Connect.]


“LWN” originally stood for Linux Weekly News (src)

People working on the Problem: Bergmann  Deepa Dinamani

Deepa is a Computer Science enthusiast. She likes thinking of why things are the way they are. Her interests are theoretical Computer Science and Operating Systems. She previously worked for Qualcomm in San Diego. Currently she works at Google in the San Francisco Bay Area. There she works on system software for data center servers, including the Linux kernel and adjacent layers. Deepa is also a Outreachy Linux Kernel Alumni. (src)






A look at the Year 2036/2038 problems and time proofness in various systems

liked this article?

  • only together we can create a truly free world
  • plz support dwaves to keep it up & running!
  • (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
  • really really hate advertisement
  • contribute: whenever a solution was found, blog about it for others to find!
  • talk about, recommend & link to this blog and articles
  • thanks to all who contribute!