@node Avoiding the year 2038 problem
@section Avoiding the year 2038 problem

The ``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-required} is like @samp{year2038},
except it rejects platforms where @code{time_t} cannot represent
timestamps after 2038, and it lacks a @option{--disable-year2038}
option.  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
@samp{ac_year2038_required=no}; however, the resulting programs will
mishandle timestamps after 2038.

The Gnulib module @samp{year2038-required} is
recommended for packages intended for use on 32-bit platforms
after the year 2038.  However, if your package needs to support
32-bit platforms that will not be used after the year 2038,
you can use the @samp{year2038} module instead.

If the Gnulib module @samp{largefile} is used but neither
@samp{year2038} nor @samp{year2038-required} 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-required}.
@xref{Large File Support}.

With the @samp{year2038-required} module, @command{configure} fails
on the following 32-bit platforms (or ABIs in bi-arch systems):
@itemize
@item
Linux with glibc < 2.34 on
x86, arm, mips (32-bit or n32 ABI), powerpc, sparc, s390, hppa, m68k, sh, csky, microblaze, nios2,
@item
Linux with musl libc on x86,
@item
Linux/riscv32,
@item
Mac OS X on x86 and powerpc,
@item
GNU/Hurd/x86,
@item
GNU/kFreeBSD/x86,
@item
FreeBSD/x86,
@item
MidnightBSD/x86,
@item
AIX/powerpc,
@item
Solaris 10 and 11 on x86 and sparc,
@item
Cygwin/x86,
@item
Haiku/x86.
@end itemize

Whereas no failure will occur on the following 32-bit platforms or ABIs:
@itemize
@item
Linux/x86 with glibc >= 2.34 on
x86, arm, mips (32-bit or n32 ABI), powerpc, sparc, s390, hppa, m68k, sh, csky, microblaze, nios2,
@item
Linux/x86_64-x32,
@item
NetBSD on x86 and sparc,
@item
OpenBSD/x86,
@item
FreeBSD/arm,
@item
Minix 3.3.
@end itemize