Testing MySQL Behavior Under the Unix 2038 Bug

The author, a DBA team member, became curious about the widely discussed Unix 2038 bug and decided to test its effect on MySQL.

What is the "Unix 2038 Bug"?

Similar to the Y2K problem, the Unix 2038 bug arises because many Unix-like systems store time as a signed 32‑bit integer counting seconds since 1970, which overflows on 19 January 2038.

Experiment: Does MySQL Fail When the System Date Is Set to 2038?

The test involved starting MySQL, monitoring its error log, and then manually setting the system clock to a date in 2038.

After changing the date, MySQL immediately shut down.

2038-10-20T00:01:01.976322+08:00 2 [Warning] Current time has got past year 2038.
Validating current time with 5 iterations before initiating the normal server shutdown process.
2038-10-20T00:01:01.976465+08:00 2 [Warning] Iteration 1: Current time obtained from system is greater than 2038
... (additional warnings) ...
2038-10-20T00:01:01.976634+08:00 2 [ERROR] This MySQL server doesn't support dates later than 2038

Root Cause

MySQL’s timestamp type supports dates only up to 2038‑01‑19 03:14:07.999999. In the source file sql/sql_parse.cc, a check aborts the server if the current time exceeds this limit, due to the internal my_time_t being 32‑bit.

/*
If the time has gone past 2038 we need to shutdown the server. But
there is possibility of getting invalid time value on some platforms.
For example, gettimeofday() might return incorrect value on solaris
platform. Hence validating the current time with 5 iterations before
initiating the normal server shutdown process because of time getting
past 2038.
*/
/*
If the time has got past 2038 we need to shut this server down.
We do this by making sure every command is a shutdown and we
have enough privileges to shut the server down

TODO: remove this when we have full 64 bit my_time_t support
*/

Impact Scope

Both MySQL 5.7.34 and 8.0.25 (the latest releases at the time of writing) contain this logic, meaning all current MySQL versions will automatically stop in 2038.

Solution

The recommended mitigation is to upgrade to a future MySQL version that supports a 64‑bit my_time_t before the year 2038; otherwise the server will become unusable.