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. Start by searching for timestamp, time_t, and int to find potentially affected code. 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
In MySQL 8.0.28 and later, UNIX_TIMESTAMP(), FROM_UNIXTIME(), and CONVERT_TZ() support dates into year 3001 on compatible 64-bit platforms. The TIMESTAMP column type remains limited to 2038. Store later dates as DATETIME, or store epoch seconds in a BIGINT, and ensure application code uses 64-bit integer types. Unlike TIMESTAMP, DATETIME does not automatically convert between the session time zone and UTC.
MariaDB
MariaDB 11.5 and later extend TIMESTAMP to 2106-02-07 06:28:15 UTC on supported 64-bit platforms. This postpones the limit; use DATETIME or BIGINT epoch seconds for dates beyond that range.
PHP
On 32-bit PHP builds, integer Unix timestamps are limited to 2038. Check PHP_INT_SIZE: a value of 8 means PHP uses 64-bit integers. Use a 64-bit PHP build when working with integer timestamps beyond 2038. DateTimeImmutable can represent later dates even on 32-bit builds, but getTimestamp() still requires the result to fit in a PHP integer; keep dates as objects or formatted strings when it does not.
C and C++ on 32-bit systems
Do not store epoch seconds in int or int32_t, and avoid configurations that use a 32-bit time_t. On affected 32-bit Linux targets with glibc 2.34 or later, compile with -D_TIME_BITS=64 and -D_FILE_OFFSET_BITS=64. Check runtime support and compatibility with libraries that exchange time_t values or related structures. On Microsoft C and C++, do not define _USE_32BIT_TIME_T or use the _time32 functions; use 64-bit time_t and time functions instead. Also check database fields, file formats, APIs, and network protocols for epoch values stored in signed 32-bit integers.
SQL Server
In SQL Server 2022 and earlier, the number argument of DATEADD is limited to a signed 32-bit integer. SQL Server 2025 supports a bigint argument. To calculate epoch seconds, use DATEDIFF_BIG(SECOND, ...) instead of DATEDIFF (available since SQL Server 2016). The datetime, datetime2, and date types support dates through 9999-12-31. Prefer datetime2 for new date and time columns, and avoid storing epoch seconds in an int.