The Year 2038 problem: what a 32-bit timestamp does

How to use

1. Type a whole number of seconds since 1970-01-01T00:00:00Z in the box (negative numbers are before 1970). The buttons fill in the interesting values.
2. The big line says what a signed 32-bit time_t holding that number would mean when read back. If the number fits, that is the real date. If it does not fit, the stored value has wrapped around and the line shows the wrong date a program would see.
3. The table below it gives the real UTC time, the stored value and the date it is read as, for both a signed and an unsigned 32-bit field.
4. The second table steps through the rollover: the last second that fits, the first that does not, and the neighbours.
5. The countdown shows the time from now (your device clock) until 03:14:08 UTC on 19 January 2038. After that moment it reads "Already passed" and shows how long ago it was. It uses your device's clock and nothing else.

Worked examples

Every result printed here is recomputed by an automated test. The wrap uses exact integer arithmetic (BigInt), and the instants are also checked against JavaScript's Date in the tests.

The key instants of a 32-bit count

The rollover

One second after the last good value, a signed 32-bit field reads as 13 December 1901, 68 years before the epoch. An unsigned field still has room: it reads 03:14:08, the correct time, and keeps going until 2106.

The unsigned limit in 2106

An unsigned 32-bit counter wraps to 0, which both readings show as the epoch itself.

The other end: dates before 1901

A birth date in 1900 stored as a signed 32-bit count wraps forward to 2038. This is the same limit at the other end.

An ordinary date

How long is left, from a fixed moment

This is counted from a fixed instant, 00:00 UTC on 1 October 2026 (Thursday), not from the moment you read this, so the numbers on this page never change. From that instant the signed limit was 356,670,848 seconds away, a little over 11 years. For the live figure, use the countdown in the demo above: it is computed from your device's clock every second.

What goes wrong

"We have until 2038"

Software that handles dates in the future reaches the limit early. A 30-year loan or a 20-year certificate created in 2026 has an end date (2056 or 2046) after 2038-01-19, and cannot be stored in a signed 32-bit field. Try 2208988800 (the first second of 2040) in the converter above: a signed 32-bit field would read it back as 25 November 1903.

"A 64-bit machine is safe"

Only the data held in 64-bit fields is safe. File formats, protocols and database columns defined with 32 bits stay limited when the CPU is 64-bit (see the MySQL TIMESTAMP example in the FAQ).

Confusing signed and unsigned

The same stored 32 bits read as 1901 when interpreted as signed and as 2038 when interpreted as unsigned. Two systems that share a file can disagree about a date without either being buggy. The table in the live demo shows both readings of each value.

Mixing it up with the 2036 NTP rollover or with Y2K

NTP's 32-bit field counts from 1900 and wraps in 2036; Y2K was about two-digit years in decimal. Different epochs, different limits, different fixes.

Limits & gotchas

• The demo is arithmetic, not an emulation. It shows what the integer wrap means, using two's complement. It cannot tell you what your program, library or database does at that moment.
• Which systems are affected is not listed here. The page states what the sources say (the Linux kernel documentation on 32-bit architectures, glibc's _TIME_BITS=64, the MySQL TIMESTAMP range) and does not claim to audit any product. Check the documentation of the product you use.
• The countdown uses your device's clock, which can be wrong. Leap seconds are not counted: a Unix timestamp ignores them, so the counter reaches 2147483648 at exactly 03:14:08 UTC as the clocks of Unix-time systems show it.
• The 2036 NTP figure is an arithmetic result from the NTP epoch (1900-01-01) and is checked against the era table in RFC 5905; it describes the field, not the behaviour of any NTP implementation.
• Whole seconds only. The demo takes integers; a fraction is refused because a 32-bit time_t has none.

FAQ

Sources

• Wikipedia: Year 2038 problem Used for: A signed 32-bit time_t overflows at 03:14:07 UTC on 19 January 2038 and wraps to 20:45:52 UTC on 13 December 1901.
• The Linux kernel documentation: timekeeping: ktime accessors Used for: The statement that the tv_sec member overflows in the year 2038 on 32-bit architectures.
• man7.org (Linux man-pages): feature_test_macros(7) Used for: _TIME_BITS=64 makes time_t 64-bit in glibc 2.34 and later (the way to avoid the 2038 limit on 32-bit systems that use glibc).
• Oracle: MySQL 8.4 Reference Manual: The DATE, DATETIME, and TIMESTAMP Types Used for: TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC; TIMESTAMP values are converted from the connection's time zone to UTC for storage and back on retrieval, so changing the time zone changes the value read back.
• PostgreSQL Global Development Group: PostgreSQL 18: Date/Time Types Used for: timestamp and timestamptz have a range of 4713 BC to 294276 AD with 1 microsecond resolution.
• IETF (RFC Editor): RFC 5905: Network Time Protocol Version 4, section 6 (time scale and era table) Used for: NTP timestamps count seconds from 1900-01-01 in an unsigned 32-bit field that wraps around in 2036 when era 1 begins; the era table lists 8 Feb 2036 as the first day of era 1 with an era offset of 63,104 seconds.
• The Open Group: POSIX.1-2024 Base Definitions, 4.19 Seconds Since the Epoch Used for: Seconds since the Epoch "approximates" the seconds elapsed since the Epoch; the formula that relates a UTC date to it for years from 1970 and non-negative values; "If the year is <1970 or the value is negative, the relationship is undefined"; "each and every day shall be accounted for by exactly 86400 seconds" (so leap seconds are not counted); the relationship to actual UTC is unspecified.
• MDN Web Docs: Date Used for: The supported range (April 20, 271821 BC to September 13, 275760 AD, plus or minus 100,000,000 days); that Date ignores leap seconds; Number.MAX_SAFE_INTEGER is 9,007,199,254,740,991; the date-time string format (a simplification of ISO 8601, 24:00:00 allowed, expanded years of + or - followed by six digits, -000000 disallowed); and that setting a local time inside a DST transition follows the Temporal "compatible" disambiguation: if the local time corresponds to two instants the earlier one is chosen, and if it does not exist the result goes forward by the gap duration (with the New York 2024 example).

Every document above was opened and read on 2026-10-03. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.

Related tools

• Unix epoch converter

  Seconds, milliseconds, microseconds or nanoseconds to a date and back, with the unit guess explained and exact BigInt arithmetic.

• ISO 8601 and RFC 3339 validator

  Check a date-time against both formats and see exactly why a string is or is not valid.

• Date difference and add/subtract

  Calendar and elapsed-time arithmetic that is honest about DST, with month-end clamping explained.

• Time zone converter

  Convert a local time between IANA zones and see what happens when the time does not exist or happens twice.