On Wed, Nov 6, 2024 at 2:11 PM Gregory Nutt <spudan...@gmail.com> wrote: > 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>
Thank you Greg!! That proves int64_t is widely adopted and kinda standard now :-) Having this as kconfig selectable configuration option that can be manually switched to int32_t or uint32_t provides choice to delopers and no surprises :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
