blob: 213fda235f27c08ba827f392389fbfcb23a8aba4 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
@node Avoiding the year 2038 problem
@section Avoiding the year 2038 problem
The ``year 2038 problem'' denotes unpredictable behaviour of programs
that will likely occur in the year 2038, for programs that use a 32-bit
@samp{time_t} type. See @url{https://en.wikipedia.org/wiki/Year_2038_problem}
for details.
The Gnulib module @samp{year2038} attempts to avoid this problem, by
ensuring that @code{time_t} is a 64-bit type and by causing
@code{configure} to fail otherwise.
The Gnulib module @samp{largefile} also attempts to avoid this problem
when possible, because @samp{largefile} enables the widest
file-related types supported by the system and @code{time_t} is one of
those types. However, @code{largefile} does not cause
@code{configure} to fail when the year 2038 problem is not avoidable.
The Gnulib @samp{largefile} and @samp{year2038} modules are
recommended for any package that might be used after the year 2038 on
32-bit platforms. However, if you build such a package you can
disable its use of 64-bit @code{time_t} by giving the
@code{--disable-year2038} option to @code{configure}. 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.
|
