Developer Tools·4 min read

What Is Unix Time? Epoch Seconds and Timezone Bugs

So what is unix time, really? It's a single integer: the number of seconds elapsed since 1970-01-01T00:00:00Z, an instant known as the epoch. No timezone, no daylight saving, no calendar quirks, just a count. That simplicity is why databases, JWTs, and log pipelines all speak it, and why so many bugs appear at the exact moment someone converts that count into a human-readable date. This guide covers the mechanics, conversions you can verify yourself, the timezone traps, and the 2038 limit built into 32-bit systems.

Open the tool All insights

The reminder that arrived five hours late

Wall clocks lie, counters don't.

A scheduling feature stores 9:00 AM as a plain local string, a user books a reminder while traveling, and the notification lands five hours off. The string looked unambiguous on the developer's machine, in the developer's timezone. The moment two zones were involved, the same text meant two different instants.

Storing epoch seconds sidesteps the entire class of bugs, because 1719912345 means one exact moment for every machine on earth. The conversion to a wall-clock time happens once, at display time, in whichever zone the viewer occupies.

What is unix time, precisely

Epoch 0 is 1970-01-01T00:00:00Z. Every Unix timestamp counts seconds forward from there, and negative values count backward, so -86400 lands on December 31, 1969. The count deliberately ignores leap seconds, treating every day as exactly 86,400 seconds, which keeps arithmetic clean at the cost of drifting a few seconds from atomic time.

You'll meet the count in two resolutions: seconds, currently 10 digits, and milliseconds, currently 13. JavaScript's Date.now() returns milliseconds while most Unix tools and JWT claims use seconds, and confusing the two is the single most frequent epoch bug.

Worked conversions you can verify

Take 1719912345 and run it through the Unix Timestamp Converter: it resolves to 2024-07-02T09:25:45Z. Run the reverse direction with the ISO date 2025-01-01T00:00:00Z and you get 1735689600 seconds, or 1735689600000 in milliseconds.

Both are checkable anywhere: date -u -d @1719912345 on Linux prints the same instant, and new Date(1719912345 * 1000).toISOString() agrees in a browser console. Deterministic conversions are the point; if two tools disagree, one of them was fed different input.

Timezones and epoch time

An epoch value has no timezone. It identifies an instant, and timezones only enter when you render that instant as a wall-clock date. 1735689600 is midnight in London, 5:30 AM in Mumbai, and 7 PM the previous evening in New York, all simultaneously and all correct.

This is why the converter shows a UTC row and a Local row side by side. When a log timestamp looks wrong by exactly your UTC offset, nothing is corrupted: something in the pipeline rendered local time where you expected UTC, or the reverse. The epoch value underneath was right all along.

The 2038 problem, in one integer

Systems that store Unix time in a signed 32-bit integer run out of room at 2147483647 seconds, which is 2038-01-19T03:14:07Z. One second later the value overflows to a large negative number, and the date snaps back to December 1901.

Modern 64-bit platforms already store time in wider types, pushing the limit billions of years out. The risk lives in embedded devices, old file formats, and database columns declared as 32-bit integers years ago, some of which will still be running in 2038. If you're defining a schema today, make the timestamp column 64 bits and move on.

Epoch mistakes that produce impossible dates

When a converted date looks absurd, check these in order:

Milliseconds fed into a seconds field. The result lands tens of thousands of years in the future; divide by 1,000 and sanity returns.
Seconds fed into a milliseconds API. Everything clusters suspiciously close to January 1970.
Parsing an ISO string without its Z suffix. Many parsers treat zoneless strings as local time, silently shifting the instant by your offset.
Adding 86,400 seconds to get tomorrow. Across a daylight saving transition, the wall-clock time shifts by an hour even though the arithmetic was correct.
Comparing a seconds value against a milliseconds value and concluding that thirteen digits is always bigger. Same instant, different units.

Tips for keeping timestamps honest

Store UTC epoch values everywhere and convert to local time only at the last rendering step. The fewer places a timezone opinion exists in your stack, the fewer places it can be wrong.

When logging, print both the epoch value and the ISO form, so 1719912345 and 2024-07-02T09:25:45Z travel together. Future debuggers, including you, get a machine-readable value and a human-readable one in the same line. And make the ten-versus-thirteen digit check a reflex.

Where timestamps lead you next

Scheduled jobs are the natural neighbor of epoch debugging. The Cron Expression Parser shows the next run times of any schedule in UTC, which you can then compare against the epoch values your job logged.

Auth tokens are the other frequent source of raw epoch seconds: the exp and iat claims inside a JSON Web Token. The JWT Decoder reads those claims out and converts the expiry for you in one paste.