Is postgres ready for 2038?

Hello dear pgsql hackers

I think Postgres had fix 2038 problems since 8.4, when I read in
stackexchange:

https://dba.stackexchange.com/a/233084/102852

So I test on my PC by simply change system date to `2040-09-25`:

- Windows 10 Home edition
- CPU: AMD 64 bit
- Postgres version 13.1 64-bit
- Postgres version 10.14 64-bit

Both Postgres edition seems basically work:

- Postgres can start the process, and connect with psql/pgAdmin
successfully. (but not show as “started” in services.msc)
- Table with the Timestamp column, test with basic CRUD sql is work.

But there are many strange logs, like:

cat postgresql-2040-09-25_123738.log

> 1904-08-20 06:09:23.083 JST [7520] LOG: stats_timestamp 2000-01-01
09:00:00+09 is later than collector's time 1904-08-20 06:09:23.083102+09
for database 0

> 1904-08-20 06:10:23.226 JST [13904] LOG: stats collector's time
2000-01-01 09:00:00+09 is later than backend local time 1904-08-20
06:10:23.22678+09

> 1904-08-20 06:10:23.227 JST [7520] LOG: stats_timestamp 2000-01-01
09:00:00+09 is later than collector's time 1904-08-20 06:10:23.227854+09
for database 12938

Note that log file name is OK, but logs content mix many time stamps (e.g
1904-08-20, 2000-01-01).

And I also found someone says in

https://www.postgresql-archive.org/Year-2038-Bug-td1990821.html

> PostgreSQL 8.4 uses 64bit data type for time. But if you use system
timezone

> then you can get in trouble if system does not support 64bit zic files.

But IMO output content in logs is not OS problems, it should be Postgres’s
2038 bug.

As our products has 15 years support period, we need to think about 2038
seriously from now,

Is there any road map for 2038 problems in Postgres?

Best regards,

Fang