SESK: Stuff Everyone Should Know · sesk.info/tech-year-2038-problem
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.
- It overflows and cannot represent later timestamps ✔
- It resets to the year 2000
- 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 2038 problem is just Unix time saying: I need a bigger number, I am only 32 bits.
Like this card?
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.
- 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.
More stuff everyone should know
That's stuff everyone should know.