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
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
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).
Not all areas of the Linux kernel are future-proof against the year 2038 problem. The ext4 file systems 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
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
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
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