We currently store all of our timestamps as int in MySQL/PostgreSQL. Before the 2038 problem happens, we need to address it. That is approximately 12 years away.

The easiest move is to just change to a bigint. This changes us from 32 bits to 64 bits, moving the problem beyond any future date we will worry about.

Most applications (Such as PHP) have moved to ensure that the UNIX time stamp returned by them is 64 bits. Operating systems have as well. The biggest problem would be running a 32-bit application or 32 32-bit OS. Both of which are becoming quickly deprecated.

This simply means, in reality, to support this, we should just as mentioned move to big ints. No additional code changes are required. Most notably for large forums, the messages table will be the hardest one to move and will be the most notable for an increase in storage. Due to the simple moving of a 4-bit int to an 8-bit bigint.

I'm initially going to pin this for 3.0. I don't think the work is horrible to get us there, and it removes any worry about any future forums breaking even if left running for another decade and a half.

MySQL/MariaDB/Precona unix_timestamp

MySQL's unix_timestamp currently returns a 32-bit int. This is currently the major problem. This was a test I performed a few years ago, but MySQL wouldn't start up. The good thing is we have moved to MySQL 8.0, so the problem is mitigated.

Jan 02 00:00:10 testbox mysqld[166008]: 2042-01-02  0:00:10 0 [ERROR] This MySQL server doesn't support dates later than 2038
Jan 02 00:00:10 testbox systemd[1]: mysqldb.service: Main process exited, code=exited, status=1/FAILURE

MySQL 8.0 seems to have support for 64-bit ints: https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-additions
This requires a 64-bit system and 64-bit MySQL. They seem to have imposed a limit to the year 3001. But this moves the problem long ways out.

MariaDB and Precona also seem to have this problem. Although lack of information regarding them and testing them. I suspect both of them will follow suit sooner or later. The resolution for MariaDB and Precona is unknown currently.

PHP

PHP itself seems it would generate time() with no issue if it is built in 64-bit.

root@testbox:~# timedatectl set-ntp no
root@testbox:~# timedatectl set-time 2038-01-02
root@testbox:~# date
Sat 02 Jan 2038 12:00:01 AM PST
root@testbox:~# php -r 'echo time();'
2146032008
root@testbox:~# date
Sat 02 Jan 2038 12:00:22 AM PST
root@testbox:~# timedatectl set-time 2042-01-02
root@testbox:~# date
Thu 02 Jan 2042 12:00:01 AM PST
root@testbox:~# php -r 'echo time();'
2272262404
root@testbox:~#

PostegreSQL

Research into this has been limited. But it seems that PostgreSQL has supported for handling 2038 for many years: https://dba.stackexchange.com/questions/233073/will-postgres-handle-the-unix-epoch-problem