Re: Change time_t to signed type

[Gregory Nutt]

Here are solutions and details of implementations as implemented by 
other OSs and file systems (the year 2038 problem does apply to 
timestamps and meta-data in file systems too!  Including NFS). See 
https://en.wikipedia.org/wiki/Year_2038_problem

     Implemented solutions

 * Starting with Ruby
   <https://en.wikipedia.org/wiki/Ruby_(programming_language)> version
   1.9.2 (released on 18 August 2010), the bug with year 2038 is
   fixed,^[16]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-18> by
   storing time in a signed 64-bit integer on systems with 32-bit
   |time_t|.^[17]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-19>
 * Starting with NetBSD <https://en.wikipedia.org/wiki/NetBSD> version
   6.0 (released in October 2012), the NetBSD operating system uses a
   64-bit |time_t| for both 32-bit and 64-bit architectures.
   Applications that were compiled for an older NetBSD release with
   32-bit |time_t| are supported via a binary compatibility layer, but
   such older applications will still suffer from the Y2038
   problem.^[18]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-20>
 * OpenBSD <https://en.wikipedia.org/wiki/OpenBSD> since version 5.5,
   released in May 2014, also uses a 64-bit |time_t| for both 32-bit
   and 64-bit architectures. In contrast to NetBSD
   <https://en.wikipedia.org/wiki/NetBSD>, there is no binary
   compatibility layer. Therefore, applications expecting a 32-bit
   |time_t| and applications using anything different from |time_t| to
   store time values may break.^[19]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-21>
 * Linux <https://en.wikipedia.org/wiki/Linux> originally used a 64-bit
   |time_t| for 64-bit architectures only; the pure 32-bit ABI
   <https://en.wikipedia.org/wiki/Application_binary_interface> was not
   changed due to backward compatibility.^[20]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-Pondering2038-22>
   Starting with version 5.6
   <https://en.wikipedia.org/wiki/Linux_kernel_version_history#Releases_5.x.y>
   of 2020, 64-bit |time_t| is supported on 32-bit architectures, too.
   This was done primarily for the sake of embedded Linux
   <https://en.wikipedia.org/wiki/Linux_on_embedded_systems>
   systems.^[21]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-23>
 * GNU C Library <https://en.wikipedia.org/wiki/GNU_C_Library> since
   version 2.34 (released August 2021), added support for using 64-bit
   |time_t| on 32-bit platforms with appropriate Linux versions. This
   support can be activated by defining preprocessor macro |_TIME_BITS|
   to |64| when compiling source code.^[22]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-24>
 * FreeBSD <https://en.wikipedia.org/wiki/FreeBSD> uses 64-bit |time_t|
   for all 32-bit and 64-bit architectures except 32-bit i386, which
   uses signed 32-bit |time_t| instead.^[23]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-25>
 * The x32 ABI <https://en.wikipedia.org/wiki/X32_ABI> for Linux (which
   defines an environment for programs with 32-bit addresses but
   running the processor in 64-bit mode) uses a 64-bit |time_t|. Since
   it was a new environment, there was no need for special
   compatibility precautions.^[20]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-Pondering2038-22>

 * Network File System
   <https://en.wikipedia.org/wiki/Network_File_System> version 4 has
   defined its time fields as |struct nfstime4 {int64_t seconds;
   uint32_t nseconds;}| since December 2000.^[24]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-26>
   Version 3 supports unsigned 32-bit values as |struct nfstime3
   {uint32 seconds; uint32 nseconds;};|.^[25]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-27>
   Values greater than zero for the seconds field denote dates after
   the 0-hour, January 1, 1970. Values less than zero for the seconds
   field denote dates before the 0-hour, January 1, 1970. In both
   cases, the nseconds (nanoseconds) field is to be added to the
   seconds field for the final time representation.
 * The ext4 <https://en.wikipedia.org/wiki/Ext4> filesystem, when used
   with inode sizes larger than 128 bytes, has an extra 32-bit field
   per timestamp, of which 30 bits are used for the nanoseconds part of
   the timestamp, and the other 2 bits are used to extend the timestamp
   range to the year 2446.^[26]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-28>
 * The XFS <https://en.wikipedia.org/wiki/XFS> filesystem, starting
   with Linux 5.10, has an optional "big timestamps" feature which
   extends the timestamp range to the year 2486.^[27]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-29>
 * While the native APIs of OpenVMS
   <https://en.wikipedia.org/wiki/OpenVMS> can support timestamps up to
   31 July 31086,^[28]
   
<https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-Crazy_time,_Stanford,_1997-30>
   the C runtime library (CRTL) uses 32-bit integers for |time_t|.^[29]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-vsi-c-rtl-31>
   As part of Y2K compliance work that was carried out in 1998, the
   CRTL was modified to use unsigned 32-bit integers to represent time;
   extending the range of |time_t| up to 7 February 2106.^[30]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-32>
 * PostgreSQL <https://en.wikipedia.org/wiki/PostgreSQL> since version
   7.2, released 2002-02-04, stores timestamp WITHOUT TIMEZONE as
   64-bit.^[31]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-33>
   ^[/failed verification
   <https://en.wikipedia.org/wiki/Wikipedia:Verifiability>/] Prior
   versions already stored timestamp as 64-bit.^[/citation needed
   <https://en.wikipedia.org/wiki/Wikipedia:Citation_needed>/]
 * As of MySQL <https://en.wikipedia.org/wiki/MySQL> 8.0.28, released
   in January 2022, the functions |FROM_UNIXTIME()|,
   |UNIX_TIMESTAMP()|, and |CONVERT_TZ()| handle 64-bit values on
   platforms that support them. This includes 64-bit versions of Linux,
   macOS, and Windows.^[32]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-34> ^[33]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-35> In
   older versions, built-in functions like |UNIX_TIMESTAMP()| will
   return 0 after 03:14:07 UTC <https://en.wikipedia.org/wiki/UTC> on
   19 January 2038.^[34]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-36>
 * As of MariaDB <https://en.wikipedia.org/wiki/MariaDB> 11.5.1,
   released in May 2024, the data type |TIMESTAMP| and functions
   |FROM_UNIXTIME()|, |UNIX_TIMESTAMP()|, and |CONVERT_TZ()| handle
   unsigned 32-bit values on 64-bit versions of Linux, macOS, and
   Windows.^[35]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-37> This
   extended the range to 2106-02-07 06:28:15 and allowed users to store
   such timestamp values in tables without changing the storage layout
   and thus staying fully compatible with existing user data.
 * Starting with Visual C++
   <https://en.wikipedia.org/wiki/Visual_C%2B%2B> 2005, the CRT uses a
   64-bit |time_t| unless the |_USE_32BIT_TIME_T| preprocessor macro is
   defined.^[36]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-38>
   However, the Windows API <https://en.wikipedia.org/wiki/Windows_API>
   itself is unaffected by the year 2038 bug, as Windows
   <https://en.wikipedia.org/wiki/Microsoft_Windows> internally tracks
   time as the number of 100-nanosecond intervals since 1 January 1601
   in a 64-bit signed integer, which will not overflow until year
   30,828
   
<https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_30,828>.^[37]
   <https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-39>