the year 2038 problem

2038 is coming soon.

At 03:14:07 UTC on January 19, 2038, every system that still counts time as a signed 32-bit number runs out of digits.

-- days
-- hours
-- minutes
-- seconds

What is the Year 2038 problem?

Many Unix-based systems represent time internally as time_t, a count of seconds since the "Unix epoch," January 1, 1970. On a huge number of systems, time_t is stored as a 32-bit signed integer, which can only count as high as 2,147,483,647.

That counter runs out at 03:14:07 UTC on January 19, 2038. One second later, it overflows and wraps around to a large negative number — which most software interprets as December 13, 1901. Any code that relies on time moving forward, or on dates being reasonable, can misbehave: logs, schedules, certificates, financial calculations, and anything else that touches the clock.

Who's affected?

Most modern 64-bit systems already use a 64-bit time_t, which pushes the same problem out roughly 292 billion years — effectively solved. The risk is concentrated in older and embedded systems that are slow to update.

Timeline

FAQ

Is this the same as the Y2K bug?
It's similar in spirit — a fixed-width date representation running out of room — but a different mechanism. Y2K was about two-digit years; 2038 is about a 32-bit integer overflowing.
Will my phone or laptop be affected?
Almost certainly not. Modern phones, laptops, and servers use 64-bit time representations, which don't hit this limit for billions of years.
What should I do about it?
If you maintain embedded systems, firmware, or older codebases that store timestamps as 32-bit integers, start planning a migration to 64-bit time types well before 2038.
Why does this site exist?
This is a placeholder — more detail on the 2038 problem is coming soon.