Good to know: The Year 2038 Problem | Expertise
March 2022
In Unix-based systems, such as Linux or BSD, ‘Unix time’ is used as the standard for measuring time. Unix time is defined as the number of seconds that have elapsed since 1 January 1970, 00:00:00 UTC, which means, for example, that 1 January 2022 at 00:00:00 UTC corresponds to a Unix time of 1640991600 seconds. [1]
In Unix-like systems, this Unix time was—and in some cases still is—stored as a signed 32-bit integer, resulting in a maximum capacity of 2,147,483,647 seconds, or just under 68 years.
Counting from the starting point, 1 January 1970, 00:00:00 UTC, this maximum capacity will be reached on 19 January 2038 at 03:14:07 UTC and exceeded in the very next second. The immediate consequence of such a counter overflow would be a change in sign and, consequently, a jump back to 13 December 1901, 20:45:52 UTC within the affected systems.
Whilst this problem is of limited relevance for systems based on 64-bit architectures due to the increased capacity to that of a 64-bit integer, systems based on 32-bit architectures are particularly at risk of exhibiting unpredictable, potentially erroneous behaviour on 19 January 2038 [2].
This problem is of particular relevance in the field of embedded systems, as embedded systems, on the one hand, have very long planned lifespans – often spanning several decades – and, on the other hand, a large proportion of the hardware currently in use is still based on 32-bit architectures.
As a way of circumventing this problem, changing the Unix time data type from a 32-bit to a 64-bit integer has proven effective, even in operating systems for 32-bit architectures. Whilst this change was implemented very early on in some operating systems – such as NetBSD with version 6.0 in 2012 or OpenBSD with version 5.5 in 2014 – the Linux kernel has only supported 64-bit data types for time on 32-bit architectures since 2020, with version 5.6 [3] [4] [5].
Despite the transition to 64-bit data types within the kernel, there are still a number of hurdles for operating systems as a whole, including:
- Affected software libraries, foremost among them the implementations of the C Standard Library, must be adapted to the new 64-bit data types and system calls.
- musl libc: full support for the new data types and system calls since version 1.2 [6]
- glibc: new data types and system calls have been implemented since version 2.32, but are still not fully supported even in the current version 2.34 [7] [8] - All programmes or applications based on these affected libraries must be recompiled using the adapted versions of the libraries.
- For applications that use direct system calls affected by the changes, a corresponding adaptation is necessary.
- Affected file systems, such as ext2, ext3 and, to some extent, ext4, may need to be adapted or replaced with others.
Although some progress has already been made in user space with regard to the 2038 problem – such as the partial implementation and support of the new 64-bit data types and system calls by the C standard libraries – the prerequisites are still lacking in some areas to protect both existing and new systems based on 32-bit architectures from erroneous behaviour in 2038.
We will continue to monitor developments in this area closely and will inform you promptly as soon as the necessary conditions for taking appropriate action have been met.
References
[1] Published by: The Open Group, “General Concepts,” [Online]. Available: pubs.opengroup.org/onlinepubs/009695399/xrat/xbd_chap04.html. [Accessed 17 February 2022].
[2] Published by: The Open Group, “64-bit and Data Size Neutrality,” [Online]. Available: unix.org/whitepapers/64bit.html. [Accessed 17 February 2022].
[3] Published by: OpenBSD, “OpenBSD 5.5 Changelog,” [Online]. Available: www.openbsd.org/plus55.html. [Accessed 17 February 2022].
[4] Published by: NetBSD, “Announcing NetBSD 6.0,” [Online]. Available: www.netbsd.org/releases/formal-6/NetBSD-6.0.html. [Accessed 17 February 2022].
[5] A. Bergmann, “[GIT PULL] y2038: core, driver and file system changes,” [Online]. Available: lkml.org/lkml/2020/1/29/355. [Accessed 17 February 2022].
[6] Edited by: musl libc, “musl time64 Release Notes,” [Online]. Available: musl.libc.org/time64.html. [Accessed 17 February 2022].
[7] Published by: GNU – Free Software Foundation, “The GNU C Library version 2.32 is now available,” 6 August 2020. [Online]. Available: sourceware.org/pipermail/libcannounce/2020/000029.html. [Accessed 17 February 2022].
[8] Published by: GNU – Free Software Foundation, “The GNU C Library: 64-bit time symbol handling in the GNU C Library,” [Online]. Available: www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html. [Accessed 17 February 2022].
