@node Avoiding the year 2038 problem @section Avoiding the year 2038 problem The @dfn{year 2038 problem} denotes unpredictable behaviour that will likely occur in the year 2038, for programs that use a 32-bit signed integer @samp{time_t} type that cannot represent timestamps on or after 2038-01-19 03:14:08 UTC@. See @url{https://en.wikipedia.org/wiki/Year_2038_problem, Year 2038 problem} for details. The Gnulib module @samp{year2038} fixes this problem on some platforms, by making @code{time_t} wide enough to represent timestamps after 2038. This has no effect on most current platforms, which have timestamps that are already wide enough. However, @samp{year2038} by default arranges for builds on legacy 32-bit Linux kernels running glibc 2.34 and later to compile with @samp{_TIME_BITS=64} to get wider timestamps. On older platforms that do not support timestamps after the year 2038, @samp{year2038} causes @command{configure} to issue a warning but still proceed. On platforms that appear to support post-2038 timestamps but where something prevents this from working, @command{configure} fails. The default behavior of @samp{year2038} can be overridden by using the @command{configure} option @option{--disable-year2038}, which suppresses support for post-2038 timestamps. This may be useful if the package links to other libraries whose user-facing ABIs still require @code{time_t} to be 32-bit on your platform. The Gnulib module @samp{year2038-recommended} is like @samp{year2038}, except it by default rejects platforms where @code{time_t} cannot represent timestamps after 2038. If this module is used and a 32-platform cannot support 64-bit @code{time_t}, one can still fix the year-2038 problem by using a 64-bit instead of a 32-bit build, as noted in the architecture list below. If all else fails one can configure with @option{--disable-year2038}; however, the resulting programs will mishandle timestamps after 2038. The Gnulib module @samp{year2038-recommended} is designed for packages intended for use on 32-bit platforms after the year 2038. If your package is commonly built on 32-bit platforms that will not be used after the year 2038, you can use the @samp{year2038} module instead, to save builders the trouble of configuring with @option{--disable-year2038}. If the Gnulib module @samp{largefile} is used but neither @samp{year2038} nor @samp{year2038-recommended} is used, @command{configure} will have an option @option{--enable-year2038} that causes @code{configure} to behave as if @samp{year2038} was used. This is for packages that have long used @samp{largefile} but have not gotten around to upgrading their Gnulib module list to include @samp{year2038} or @samp{year2038-recommended}. @xref{Large File Support}. With the @samp{year2038-recommended} module, @command{configure} by default should work on the following 32-bit platforms (or 32-bit ABIs in bi-arch systems): @itemize @item Linux kernel 5.1 (2019) and later with glibc 2.34 (2021) and later on x86, arm, mips (o32 or n32 ABI), powerpc32, sparc32, s390, hppa, m68k, sh, csky, microblaze, nios2, @item Linux kernel 5.1 (2019) and later with musl libc 1.2 (2020) and later on x86, @item Linux on arc, loong32, ork1, riscv32 and x86_64-x32, @item NetBSD 6.0 (2012) and later on x86 and sparc, @item OpenBSD 5.5 (2014) and later on x86, @item FreeBSD/arm, @item Minix 3.3 (2014). @end itemize @noindent Whereas with @samp{year2038-recommended}, @command{configure} should by default fail on earlier versions of the abovementioned platforms if a version is listed, and it should also by default fail on all versions of the following older 32-bit platforms or ABIs: @itemize @item Android on ARMv7 or x86, @item Mac OS X 10.6 (2009) and earlier on x86 and powerpc, @item GNU/Hurd/x86, @item GNU/kFreeBSD/x86, @item FreeBSD/x86 (this port demoted to Tier 2 in FreeBSD 13 [2021] and planned to never have 64-bit @code{time_t}), @item MidnightBSD/x86, @item AIX/powerpc (to fix, configure with @samp{CC='gcc -maix64' AR='ar -X64'}), @item Solaris 11.4 (2018) and earlier on x86 and sparc (to fix, configure with @samp{CC='gcc -m64'}), @item Cygwin 3.3.6 (2022) and earlier on x86, @item Haiku/x86. @end itemize If you use the @samp{year2038} or @samp{year2038-recommended} modules, and configure to support timestamps after the year 2038, your code should not include @samp{} or @samp{} directly, because these include files do not work with 64-bit timestamps if the platform's @code{time_t} was traditionally 32 bits. Your code can instead use the @samp{readutmp} module, which works around this problem.