Unix Timestamps Will Break Your Code in 2038

On January 19, 2038, at 03:14:07 UTC, something interesting will happen to a lot of software. Unix timestamps stored as 32-bit signed integers will overflow, wrapping around from 2,147,483,647 to -2,147,483,648. Systems that use this timestamp representation will suddenly think it's December 13, 1901.

This is the Year 2038 problem, and while most modern systems have moved to 64-bit timestamps, a surprising amount of legacy code hasn't.

What Unix Timestamps Actually Are

A Unix timestamp is conceptually simple: the number of seconds since January 1, 1970, 00:00:00 UTC (the "Unix epoch"). Right now, it's a 10-digit number somewhere around 1.7 billion. By 2038, it'll hit the 32-bit signed integer limit.

Why seconds since an arbitrary date in 1970? Because the original Unix designers needed to pick something, and the early 70s was recent enough to be useful while being computationally convenient.

The elegance is in the simplicity. Unlike human-readable dates with their time zones, daylight saving, leap seconds, and calendar quirks, a Unix timestamp is just a number. Easy to store, easy to compare, easy to do math on.

Milliseconds vs. Seconds: The JavaScript Twist

Here's a common source of bugs: JavaScript's Date.now() returns milliseconds since epoch, not seconds. So while the current Unix timestamp might be around 1,734,600,000 (seconds), JavaScript gives you 1,734,600,000,000 (milliseconds).

Forget this conversion when talking to a backend API that expects seconds, and your dates will be about 53 years in the future. I've seen this break production systems more than once.

The quick test: if your timestamp is 10 digits, it's probably seconds. If it's 13 digits, it's probably milliseconds.

Time Zones: Where Things Get Messy

Unix timestamps have no time zone—by definition, they're UTC. But converting to a human-readable format requires choosing a time zone, and this is where bugs breed.

Consider this: you store a user's appointment time as a Unix timestamp. Simple. But when you display it:

• What time zone should you use?
• What if the user travels?
• What about daylight saving time transitions?

The timestamp itself is unambiguous, but its interpretation isn't. Many applications get this wrong, showing 2:00 PM to someone in New York when the appointment is actually at 2:00 PM Pacific.

ISO 8601: The Readable Alternative

For most modern applications, ISO 8601 format (2025-12-19T15:30:00Z) is a better choice for storage and transmission. It's human-readable, self-documenting, and explicitly includes offset information.

But timestamps still have their place:

• Database sorting. Integer comparison is fast and simple.
• Time math. Adding 3600 seconds is cleaner than parsing dates.
• Compactness. A 10-digit number is smaller than a 20-character string.

The 2038 Problem: Are You Affected?

Most modern systems use 64-bit timestamps, which won't overflow until the year 292 billion. But here's what might still break:

Databases. MySQL's TIMESTAMP type was 32-bit until relatively recently. Old tables might still have the limitation.

Embedded systems. IoT devices, industrial controllers, and automotive systems often run 32-bit processors with 32-bit time libraries.

Serialization formats. If you're storing timestamps as 32-bit integers in binary formats, files created today might fail in 2038.

Legacy APIs. External systems you integrate with might use 32-bit timestamps. You can't control their upgrade schedule.

Practical Tips for Working with Timestamps

Always specify the unit. Name your variables createdAtSeconds or timestampMs, not just time. Future you will thank present you.

Validate ranges. If a timestamp is supposed to be "now," check that it's within a reasonable range. Timestamps from 1970 (value close to 0) or from 2100 (too high) are probably bugs.

Use libraries. Don't write date parsing code yourself. Whatever language you're using, there's a battle-tested library that handles edge cases you haven't thought of.

Be careful with time zones. Store in UTC. Convert to local time only at the display layer. Re-convert from local time back to UTC immediately after user input.

Converting Is Easier Than You Think

When you're debugging an API that returns a suspicious number, or trying to figure out when a log entry occurred, a timestamp converter saves time. Paste the number in, see the human-readable date out.

Not exciting. But useful when you're staring at 1734567890 in a log file at 2 AM trying to figure out whether something happened before or after a deployment.