Widen the clock.
Check the whole path.

64-bit seconds remove the 2038 integer limit. Applications, APIs, stored data, and conversions still need to agree.

32 → 64

Maximum positive signed integer ranges
Width	Maximum seconds	Capacity
32-bit	`2,147,483,647`Signed maximum: 2³¹ - 1	19 Jan 203803:14:07 UTC
64-bit	`9,223,372,036,854,775,807`Signed maximum: 2⁶³ - 1	~292 billion yearsArithmetic range, not a calendar API guarantee

Migration checklist

Inventory every timestamp boundaryRuntime types, database columns, serialized messages, files, and device firmware.
Use a wider time representationConfirm the actual time type and ABI, not just the CPU's bit width.
Audit conversions and castsA 64-bit value narrowed into a 32-bit field reintroduces the limit.
Test before, at, and after the boundaryInclude stored dates, comparisons, scheduled jobs, and round trips.

A planning checklist, not a compliance assessment. Selections are local to this page visit.

Platform support isn't the whole fix.

GNU's guidance supports wider timestamps through _TIME_BITS=64 on relevant glibc builds. Build configuration and compatibility with dependent libraries matter.

2038-01-19 03:14:07 UTC
2038-01-19 03:14:08 UTC
2038-01-19 03:14:09 UTC

Microsoft documents separate 32-bit and 64-bit time APIs and discourages _USE_32BIT_TIME_T. A wider integer does not mean that every date-conversion function accepts its entire arithmetic range.

GNU migration guidance Microsoft time API ranges

Compare the representations.

The same seconds, stored in 32 bits and 64 bits.

Widen the clock.Check the whole path.

Migration checklist

Platform support isn't the whole fix.

Compare the representations.

Widen the clock.
Check the whole path.