time
Unix Timestamps and Epoch Time Explained (Plus the Year 2038 Problem)
What a Unix timestamp actually is, why "the epoch" is 1970, how seconds vs milliseconds trips people up, timezones, and the Year 2038 problem — with tools to convert epoch values instantly.
You’ve seen it in logs, JSON payloads, and database columns: a big number like 1752710400 where a date should be. That’s a Unix timestamp — one of the most common and most misunderstood ways computers store time. It’s simpler than it looks, has two gotchas that cause real bugs, and one famous deadline coming in 2038. Here’s the whole picture.
What a Unix timestamp is
A Unix timestamp is the number of seconds that have elapsed since midnight UTC on January 1, 1970 — a moment called the epoch. That’s it. 1752710400 means “1,752,710,400 seconds after the epoch,” which works out to a specific instant in July 2026.
Why 1970? It’s an arbitrary but convenient origin chosen by the early Unix designers. Counting from a fixed point makes time arithmetic trivial: to find the seconds between two events, subtract. No calendars, no month lengths, no leap-year rules — just integers.
Gotcha 1: seconds vs milliseconds
This is the single most common timestamp bug. Different systems count from the epoch in different units:
| Unit | Example | Where you see it |
|---|---|---|
| Seconds | 1752710400 | Unix tools, most databases, JWT exp/iat |
| Milliseconds | 1752710400000 | JavaScript Date.now(), many JS APIs |
They differ by a factor of 1000. Feed a seconds value into something expecting milliseconds and your date lands in January 1970; do the reverse and you land in the year 57000. The quick sniff test: a current timestamp in seconds is 10 digits; in milliseconds it’s 13.
Gotcha 2: the timestamp itself has no timezone
A Unix timestamp is always UTC — it’s a count of seconds since a UTC instant, so it carries no timezone of its own. The timezone only enters when you format it for a human. The same number 1752710400 is simultaneously “5:00 PM in London” and “9:00 AM in Los Angeles.” That’s a feature: store the timestamp, apply the viewer’s timezone at display time, and you never have to reconcile stored offsets. The one place that rule fails is future events defined in local time — should you store timestamps in UTC? covers the exception.
The Year 2038 problem
Here’s the interesting deadline. Many older systems store the timestamp in a signed 32-bit integer. The largest value that holds is 2,147,483,647 — which, counted as seconds from 1970, runs out at 03:14:07 UTC on January 19, 2038.
One second later, the counter overflows and wraps around to a large negative number — interpreting the time as December 1901. It’s the same class of bug as Y2K, but rooted in integer width rather than two-digit years. Anything doing date math past 2038 on a 32-bit time_t — embedded devices, old databases, expiry calculations for long-lived contracts — can miscompute today.
The fix is already widespread: use 64-bit timestamps, which don’t overflow for another ~292 billion years. Modern languages and 64-bit operating systems default to this. The risk lives on in legacy 32-bit systems and embedded firmware that’s expensive to update.
Converting timestamps
Reading a raw epoch value by eye is impossible, so convert it:
- For a single value — paste it into the Timestamp Converter to see the human-readable date (and go the other way, date → epoch). It handles both seconds and milliseconds.
- Got a whole column of them from a log or CSV? The Epoch Batch Converter turns a list of timestamps into readable dates all at once. If those numbers came out of a spreadsheet instead of a log, they’re probably not Unix timestamps at all — Excel stores dates as its own serial-number scheme, and exporting one wrong looks similar but is a different bug entirely. See why Excel dates and IDs break on export.
- Need the gap between two moments rather than a single instant? The Duration Calculator gives you days, hours, and even business days between two dates.
All three run in your browser — paste, read, done. And if you ever see a date land in 1970 or the far future, you already know the answer: check your seconds-vs-milliseconds.