Counting seconds

Unix time is very simple: it is the number of seconds that have passed since the epoch, 1970-01-01 00:00:00 UTC (leap seconds are ignored). Some examples:

Why 32 bits?

Unix was created around 1970 on machines where memory was precious. The C type time_t, which holds the timestamp, was a signed 32-bit integer. “Signed” means one bit is reserved for the sign, so negative numbers can describe dates before 1970.

That leaves 31 bits for the value:

2^31 − 1 = 2,147,483,647 seconds ≈ 68 years

and 1970 + 68 years puts the end in 2038.

What happens at the overflow

In binary, the last valid second looks like this:

0111 1111 1111 1111 1111 1111 1111 1111
=  2147483647
→  2038-01-19 03:14:07 UTC

Add one second and the carry runs into the sign bit:

1000 0000 0000 0000 0000 0000 0000 0000
= −2147483648
→  1901-12-13 20:45:52 UTC

The clock doesn’t stop; it jumps back 136 years. Depending on the software this can mean:

• certificates, tokens and passwords that are suddenly “not yet valid” or already expired
• timeouts that fire at once, or never
• log files, backups and databases sorted in the wrong order
• schedulers, alarms and billing systems running at the wrong time
• crashes from code that never expected a negative time

It is already happening

Software doesn’t have to wait until 2038 to fail. Anything that calculates dates in the future hits the limit early: 30-year loans, long-term certificates, pension calculations, or timeouts set “far in the future”. A famous early case was the AOLserver web server. In May 2006 it crashed because its default database timeout of one billion seconds, added to the current time, pushed past 2038.

And with 64 bits?

A signed 64-bit time_t lasts about 292 billion years, roughly 20 times the age of the universe. That is the fix, and the question is only whether it has reached every place where time is stored.

Unsigned 32-bit counters, which some systems use instead, end later: on 7 February 2106, but they can’t represent any date before 1970.