Waiting for a timestamp

UTC · GMT

Local time

—

Paste an epoch number or a date string, or press the clock to use the current time.

Unix Timestamp Converter

Paste an epoch number or a date string and read it back as a real date, in UTC and in your own zone, with the unit inferred from the digit count. Seconds, milliseconds, microseconds, and nanoseconds are all recognised — which is the difference between a timestamp from 2001 and one from next Thursday.

Digits means seconds: 10
Digits means milliseconds: 13
Digits means microseconds: 16
When 32-bit time runs out: 2038

Step by step

How to use it

01Paste the value
A bare number from a log line, or an ISO string. Auto mode reads the digit count and picks the unit, which is right almost always and overridable when it is not.
02Check the unit it chose
Ten digits is seconds, thirteen is milliseconds, sixteen is microseconds, and nineteen is nanoseconds. The unit is stated explicitly, because a millisecond value read as seconds lands about 50,000 years out.
03Read it in both zones
UTC and your local zone side by side, with the offset labelled. Most timestamp confusion is really zone confusion, and seeing both at once resolves it immediately.
04Take the format you need
The ISO string for a config or an API, the human-readable form for a ticket, or the relative phrase for a sanity check on how old a record is.

Worked example

How the unit is inferred

A bare epoch number carries no unit, so digit count is the only honest signal. These are the boundaries the tool uses and the years they correspond to.

Input: a bare number
Signal: digit count
Reference: 1970-01-01 UTC

The same digits, read three ways

1767225600      10 digits -> seconds
                2026-01-01 UTC

1767225600000   13 digits -> milliseconds
                2026-01-01 UTC  (same moment)

1767225600      read as milliseconds instead
                1970-01-21  - twenty days after
                the epoch, not 2026

10 digits: seconds, until 2286
13 digits: milliseconds
Wrong unit costs: decades

Ten digits stays in the seconds range until the year 2286, which makes the heuristic safe for anything you will encounter in practice. The failure it protects you from is severe rather than subtle: a millisecond value read as seconds lands roughly fifty thousand years in the future, and a seconds value read as milliseconds lands three weeks after 1970 — both obviously wrong once you see the date, and both easy to miss in code.

Before you trust the number

What to know about epoch time

Seconds or milliseconds is the recurring bug

Unix tools, Postgres, and Go default to seconds; JavaScript, Java, and most JSON APIs use milliseconds. Passing one to the other is the most common date bug in existence, and it does not throw — it produces a date in 1970 or in the year 55000, which then gets stored.

An epoch number has no timezone

It counts seconds since a fixed instant in UTC, so the number itself is unambiguous. Every timezone question arrives at the formatting step — which is why storing epoch time and formatting per user is the right architecture, and storing local strings is not.

The 2038 problem is real and not over

A signed 32-bit seconds counter overflows on 19 January 2038. Modern platforms use 64-bit time, but embedded devices, old file formats, and databases with an int column still carry the limit — and a system computing a 20-year expiry hits it today.

Leap seconds are not represented

Unix time deliberately pretends every day has exactly 86,400 seconds, so a leap second is smeared or repeated depending on the platform. It is a rounding-level concern for most applications and a real one for anything measuring precise intervals across a leap event.

Storing local time throws information away

A wall-clock string with no offset is ambiguous on the day the clocks go back, when 01:30 happens twice. Storing epoch time or a full ISO string with an offset preserves the instant; storing 2026-10-25 01:30 does not.

Nothing is sent anywhere

Parsing and formatting run in your browser. Log lines pasted here — which routinely contain customer identifiers next to their timestamps — never leave the machine.

The judgement call

How should you store a time?

Most date bugs are storage decisions rather than formatting mistakes.

An event that happened
Epoch or UTC
An instant is an instant. Store it unambiguously and format per viewer at the edge.
A future appointment in a named place
Local time + zone
If the zone's rules change before the date, 09:00 in Berlin must still mean 09:00 in Berlin.
A birthday or a calendar date
A plain date
There is no instant involved. Storing it as a timestamp gives it a timezone it should never have had.
A duration or a timeout
Store the number
Seconds or milliseconds as an integer, with the unit in the field name. Never two timestamps you subtract later.
A column typed as 32-bit int
Fix it now
It fails in 2038, and anything computing a long expiry fails today.
A wall-clock string with no offset
Ambiguous
One hour a year happens twice. The value cannot be resolved back to a single instant.

Reference

How epoch time is defined

The epoch: 1970-01-01 00:00:00 UTCThe reference instant. Negative values are legal and represent dates before it.
Seconds: 10 digits todayStays 10 digits until the year 2286, which is what makes the digit-count heuristic dependable.
Milliseconds: 13 digitsThe JavaScript and JSON convention. Multiply seconds by 1,000 — a common source of off-by-1000 bugs.
Microseconds: 16 digitsUsed by some databases and tracing systems, notably in Python and in high-resolution logs.
2038 limit: 2,147,483,647The largest signed 32-bit value: 19 January 2038, 03:14:07 UTC. After that a 32-bit counter wraps to 1901.
Leap seconds: Not representedEvery Unix day is exactly 86,400 seconds by definition, so leap seconds are smeared or repeated by the platform.

FAQ

Questions, answered plainly

How do I convert a Unix timestamp to a date?

Paste the number. The unit is inferred from its digit count — ten digits is seconds, thirteen is milliseconds, sixteen is microseconds, and nineteen is nanoseconds — and the result is shown in UTC and in your local zone with the offset labelled. Override the unit if the value comes from a system you know uses a different one.

Is my timestamp in seconds or milliseconds?

Count the digits. A current timestamp in seconds has ten; in milliseconds it has thirteen. If a date comes out in 1970 you read milliseconds as seconds; if it lands tens of thousands of years in the future you did the reverse.

What timezone is a Unix timestamp in?

None — it counts seconds from a fixed instant in UTC, so the number itself is unambiguous. Timezones only enter when you format it for a person, which is exactly why storing epoch time and formatting at the edge is the robust pattern.

What is the year 2038 problem?

A signed 32-bit seconds counter reaches its maximum on 19 January 2038 and wraps to 1901. Most modern systems use 64-bit time, but embedded devices, older file formats, and databases with an int column still carry the limit — and any system computing a date more than a decade ahead is already affected.

Should I store dates as timestamps or strings?

Store an instant that happened as epoch time or an ISO string in UTC. Store a future appointment as local time plus its zone, so it survives a change to that zone's rules. Store a birthday as a plain date, with no time and no zone at all.

Does anything leave my browser?

No. Parsing and formatting both run locally, which matters because log lines pasted into a converter usually carry identifiers alongside their timestamps.

Parsing and formatting run entirely in your browser. Nothing you paste is transmitted or stored.

Keep going