What happens to a signed 32-bit Unix time counter in January 2038?

It runs out of room and overflows, just after 03:14:07 UTC on 19 January 2038.

Start playing free

  1. It overflows and cannot represent later timestamps ✔
  2. It resets to the year 2000
  3. Nothing, Unix time counts in minutes

Why: A signed 32-bit time_t cannot represent timestamps from 19 January 2038 at 03:14:08 UTC onward. Using a wider time_t extends the representable range beyond 2038.

Huh, didn't know that: GNU Gnulib can request 64-bit time_t values on supported legacy 32-bit Linux systems.

The dad joke
The 2038 problem is just Unix time saying: I need a bigger number, I am only 32 bits.
Like this card?
Play the game

References

Answer: It overflows and cannot represent later timestamps. A signed 32-bit time_t cannot represent timestamps from 19 January 2038 at 03:14:08 UTC onward. Using a wider time_t extends the representable range beyond 2038.

  1. GNU Gnulib manual: Avoiding the year 2038 problem www.gnu.org/software/gnulib/manual/html_node/Avoiding-the-year-2038-problem.html
    programs that use a 32-bit signed integer time_t type that cannot represent timestamps on or after 2038-01-19 03:14:08 UTC.
    Checked 2026-10-10.

Think this answer is wrong? Tap "Challenge this answer" on the card in the game and tell us why.

Test yourself in the game