when will a Y2K time overflow problem happen in modern 21st century Linux?

Question

referencing Why does Unix time start at 1970-01-01?

An answer mentioned

The end of Unix Time will occur on January 19, 2038 03:14:07 GMT. On January 19, 2038 03:14:08 GMT all computers that still use 32 bit Unix Time will overflow. This is known as the "Year 2038 problem". Some believe this will be a more significant problem than the "Year 2000 problem". The fix for the Year 2038 problem is to store Unix Time in a 64 bit integer. This is already underway in most 64 bit Operating Systems but many systems may not be updated by 2038.

• If I decide to run RHEL/CentOS 7.9 indefinitely, can someone comment on if that is running 64-bit time integer (signed or unsigned?) and when will it have a time problem?
• What is the current solution to the time overflow problem in modern linux, i.e. RHEL/CentOS 9 for example? Did They figure out this time problem a while ago like in RHEL 5, or is it still an issue that doesn't get attention?
• For whatever the current solution is, mathematically it is only good for so long correct? If so, for this best solution currently happening what is its date in the future when the time overflow will eventually happen?

Answer 1

1. 64-bit programs already handle timestamps past 2038. The main concern now is file systems; ext4 file systems with inodes larger than 128 bits (run dumpe2fs and look for “Inode size”) are fine, as are XFS file systems with kernels 5.10 and later, using the bigtime option (this is supported on RHEL 8.3 and later, I’m not sure about RHEL 7; file systems limited to 2038 produce a warning on mount).

2. The current solution is to use 64-bit timestamps wherever possible.

3. XFS supports dates until 2486 for the time being. 64-bit timestamps on Linux can represent dates until approximately the year 292,000,000,000.