Unix Timestamp Converter: What It Is and How to Use It

You are reading a log line, an API response or a database row and there it is: 1767225600. It is a date, but not one you can read. This guide explains what that number is, the traps that make it go wrong, and how to convert it in a second with our Unix Timestamp Converter.

What a Unix timestamp is

A Unix timestamp — also called epoch time, POSIX time or Unix time — is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, known as the Unix epoch. Negative values represent instants before that date.

Two properties make it the default way machines store time. First, it is a single integer: trivially comparable, sortable and subtractable, with no parsing needed. Second, it carries no time zone, because it is always counted in UTC — the same instant produces the same number everywhere on Earth. Formatting into a local date is a display concern, applied at the last possible moment.

POSIX time also ignores leap seconds by definition: a day is treated as exactly 86,400 seconds. That keeps the arithmetic simple at the cost of being a few dozen seconds away from strict atomic time — irrelevant for almost every application, and a known consideration for the handful where it is not.

The year 2038 problem

Stored in a signed 32-bit integer, a Unix timestamp overflows on 19 January 2038 at 03:14:07 UTC. Modern systems use 64-bit time values, which pushes the limit far beyond any practical horizon, but legacy embedded systems and old database columns can still be affected. If you maintain something with a 32-bit time field, that is a real deadline.

Seconds vs milliseconds: the mistake everyone makes

Unix time is defined in seconds, but several ecosystems count in milliseconds instead. JavaScript's Date.now() returns milliseconds. Java's System.currentTimeMillis() returns milliseconds. Python's time.time() returns seconds (as a float). Most Unix CLI tools and PostgreSQL's extract(epoch from …) give you seconds.

Mixing them is the single most common epoch bug, and it is instantly recognisable by the symptom:

• A date in 1970 means you fed milliseconds into something expecting seconds — the value was divided by 1000 in effect, landing just after the epoch.
• A date tens of thousands of years in the future means the reverse: seconds interpreted as milliseconds.

The quick eyeball test: a current timestamp in seconds has 10 digits; in milliseconds it has 13. Our converter applies exactly that rule — values of 10 digits or fewer are read as seconds, longer values as milliseconds — and shows you both, so a mismatch is obvious immediately.

Where developers actually meet epoch time

Debugging logs and incidents

Log lines, crash reports and metrics pipelines often store raw epoch values. During an incident you are correlating events across services, and the first job is turning three numbers into three readable UTC times so you can see the order and the gaps. Converting a couple of endpoints of a window is faster than reconfiguring a log viewer.

APIs, tokens and webhooks

JWTs carry iat, exp and nbf claims as epoch seconds — "is this token expired?" is a conversion away. Rate-limit headers such as X-RateLimit-Reset are usually epoch seconds too, as are webhook signature timestamps and OAuth expiry fields. To inspect a whole token rather than one claim, our JWT Decoder does the decoding for you.

Databases and data files

Plenty of schemas store integer epoch columns instead of a native timestamp type, and exported CSVs frequently arrive that way. Before you load or chart that data you need to know the unit and the boundary values. When you are reshaping the file itself, CSV ⇄ JSON and JSON Formatter pair well with this tool.

Scheduling and durations

Cache TTLs, cron windows, retry backoffs, "expires in" banners — all are arithmetic on epoch integers. For the gap between two timestamps use Epoch Diff, and for making sense of a cron expression try the Cron Parser.

How to use the EasyFileMagic Unix Timestamp Converter

The converter is a two-way form: change either side and the other updates instantly. Everything is computed in your browser with the standard JavaScript Date API — nothing is sent anywhere, so you can paste production timestamps into it without a second thought.

1. Open the Unix Timestamp Converter. The panel at the top shows the current time, ticking once a second, in both epoch seconds and ISO 8601.
2. Paste your value into the Unix timestamp field. Seconds and milliseconds are both accepted — 10 digits or fewer are read as seconds, longer values as milliseconds.
3. Read the ISO 8601 (UTC) field, which updates as you type. An invalid entry shows a clear error rather than a silently wrong date.
4. Going the other way? Type or paste an ISO date into the ISO field and the epoch value is filled in for you.
5. Check the Human readable panel below for four views of the same instant: UTC, your local time, local ISO, and the value in milliseconds.
6. Hit Use now for a fresh current timestamp, or Copy under either field to put the value on your clipboard.

A note on time zones

The ISO output is always UTC and ends in Z. The Local line renders the same instant in whatever time zone your browser is set to, which is why a colleague in another country will see a different wall-clock time for an identical timestamp. That is the point of epoch time: one instant, one number, many local renderings.