The Year 2038 Problem

This simulation starts 20 seconds before 2147483648.
When the counter crosses the signed 32-bit limit, the stored epoch wraps to -2147483648.
The leftmost bit is the sign bit: in signed binary, 0 means positive or zero, and 1 means negative.

What is the Year 2038 problem?

The Year 2038 problem (also called Y2038 or the Epochalypse) happens when software stores a Unix timestamp as a signed 32-bit integer. The largest value that type can hold is 2147483647, which maps to 2038-01-19 03:14:07 UTC.

After that second, at 2147483648, the value overflows and may wrap to a negative number, causing dates to jump back to 1901 or fail.

The problem can appear anywhere a 32-bit epoch value is still used in application code, APIs, databases, file formats, firmware, or third-party libraries. Software that handles future dates, such as scheduling systems, may encounter bugs well before 2038.

For Developers: How to detect and fix the problem

Review database column types and application code for signed 32-bit integers. Also look for fields with common epoch-related names, especially timestamp, time_t, and int. Add tests with timestamps around 2147483647, and verify behavior for dates before and after 2038-01-19. To fix the problem, move affected timestamps to 64-bit integers.

MySQL

Upgrade to MySQL 8.0.28 or later, which supports 64-bit integers for timestamps. Change affected columns to BIGINT and update application code to use 64-bit types. MySQL's TIMESTAMP type is limited to 2038, use DATETIME or BIGINT for future dates. UNIX_TIMESTAMP() returns a 32-bit value on MySQL versions before 8.0.28.

SQL Server

DATEADD: All SQL Server versions up to and including SQL Server 2022 use a signed 32-bit integer for the number argument of DATEADD.
SQL Server itself does not have a problem with dates after 2038; datetime, datetime2, and date can handle dates up to 9999-12-31.