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
In MySQL 8.0.28 and later, UNIX_TIMESTAMP(), FROM_UNIXTIME(), and CONVERT_TZ() support 64-bit values on compatible 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.
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. 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. SQL Server date types do not have a Year 2038 limit: datetime supports dates through 9999-12-31, while datetime2 and date support the range 0001-01-01 through 9999-12-31. Use datetime2 for new date and time columns unless compatibility requires another type, and avoid storing epoch seconds in an int.