Year 2038 Timestamp Problem
The standard Unix time format is stored as a signed 32-bit integer which counts the number of seconds passed since January 1st, 1970. This becomes a problem at 03:14:07 on Tuesday, 19 January 2038 (231-1 = 2,147,483,647 seconds after 1 January 1970) when the integer's full (integer overflow). The integer's sign bit will flip and the integer will get its maximum negative value and count up towards zero from there. A negative 32-bit integer would be interpreted as 20:45:52 on Friday, 13 December 1901.
Current Problems And Solutions[edit]
Standard Unix time being limited to dates before January 19th, 2038 is already a problem in existing poorly written software where a user is allowed to enter dates after 2038. It is typically not a problem with reasonably maintained free software programs.
Linux[edit]
The Linux kernel uses a 64-bit time_t on 64-bit architectures. The 32-bit ABI does not and Linux will keep on using a 32-bit time_t on 32-bit architectures for backwards compatibility (there are, of course, those who are trying to get support for 64-bit timestamps on 32-bit architectures into the kernel; it could happen).
File systems with an inode size of 128 bytes do not support timestamps beyond January 19, 2038. Inodes which are 256 bytes or larger will support extended timestamps, project id's, and the ability to store some extended attributes in the inode table for improved performance.
The ext3/ext4 file systems with with 128 bytes inode size will as of kernel 5.4.0 produce this warning when they are mounted:
ext4 filesystem being mounted at (mountpoint) supports timestamps until 2038 (0x7fffffff)
FreeBSD[edit]
FreeBSD uses a 64-bit time_t on all 32-bit and 64-bit architectures except for i386 where time_t remains a 32-but unsigned integer.
NetBSD took a different approach in 2012. time_t is 64-bit on all architectures including i386 on NetBSD. Applications that were compiled for earlier NetBSD versions are forced to use a 32-bit time_t using a compatibility layer.
Package-Specific Problems[edit]
The GLib GTimeVal and g_get_current_time() functions are not year 2038 safe. Both of those functions were deprecated in GLib 2.61.2 in favor of GDateTime[1]. A lot of software using glib, like Xfce, will show warnings, or errors if warnings are set to throw errors, due to the widely used GTimeVal is. As an example, xfec4-session aborts with:
xfce-settings-editor-box.c: In function ‘xfce_settings_editor_box_channel_monitor_changed’:
xfce-settings-editor-box.c:855:5: error: ‘GTimeVal’ is deprecated: Use 'GDateTime' instead [-Werror=deprecated-declarations]
855 | GTimeVal timeval;
| ^~~~~~~~
compilation terminated due to -Wfatal-errors.
Xfce and a lot of other software using glibs GTimeVal will have to be re-written before 2038.
Year 292,277,026,596 Timestamp Problem[edit]
Linux and BSD solved the year 2038 timestamp problem by switching from a 32-bit time_t to a 64-bit time_t. This solution kicks the can down the road to 15:30:08 UTC on Sunday, December 4th, 292,277,026,596.
Other problems will arise prior to the year 292,277,026,596. tm_year uses a 32-bit signed integer which starts at the year 1900. This means that years can not be calculated correctly beyond year 2,147,485,547 (2,147,483,647 + 1900).
Enable comment auto-refresher