tohya.net
I'm currently in the process of moving an old PHP application to a new framework since the one originally used is way outdated, spitting out deprecation warnings left and right. The app still uses unix timestamps to store and handle dates. 2038 is still a long time off, but I'd rather not have to work on this app again in the future so I decided to have a look into how PHP timestamps are compatible with dates beyond January 19th 2038.
The short and quick answer is that there is little to worry about. When running on 64bit systems PHP handles 64bit timestamps just well. You can check this by having a look at the PHP_INT_SIZE constant. It holds an integer representing the number of bytes used internally to store integer values and should resolve to 8 on modern systems (however things are looking bad if it resolves to a value of 4).
I've confirmed that the DateTime class handles timestamps beyond the specified date with no trouble. However I wasn't able to find any resources on how time() fetches its unix timestamp internally. It might or might not be limited to timestamps up until January 19th 2038. Fortunately replacing lines such as $t = time() with $t = (new DateTime())->getTimestamp() is all it needs to be on the safe side.
What about the database side? MySQL databases can store unix timestamps just fine with INT UNSIGNED colums. Columns only storing signed integers will eventually require to be updated. Of course BIGINT UNSIGNED type columns will let you forget about the problem altogether. Unless your app is storing its data in a MariaDB database and making use of the function UNIX_TIMESTAMP(). UNIX_TIMESTAMP() was fixed in a MySQL update to return values beyond the limit of unsigned 32bit integers. Unfortunately no such fix seems to exist for MariaDB so far. There might be an internal function to cast the return value of CURRENT_TIMESTAMP() to a unix timestamp, but this issue wasn't applicable to my particular problem so I haven't looked it up.
Conclusion
PHP apps running on modern systems have little need for custom code to support future-proof timestamps. However they might run into slight problems if they make excessive use of UNIX_TIMESTAMP() in a MariaDB database.