Unix Timestamp Converter
Paste a timestamp and see the date behind it instantly – or go the other way and turn a date and time into the matching epoch value. Seconds, milliseconds, microseconds and nanoseconds are detected automatically, and the time zone is yours to pick. Everything runs locally in your browser.
Current Unix timestamp
–––Converted
| Selected time zone | – | |
|---|---|---|
| Your local time | – | |
| UTC | – | |
| ISO 8601 / RFC 3339 | – | |
| ISO 8601 (UTC) | – | |
| RFC 7231 (HTTP date) | – | |
| Relative to now | – | |
| Weekday, ISO week, day of year | – | |
| Seconds | – | |
| Milliseconds | – | |
| Microseconds | – | |
| Nanoseconds | – |
Everything runs locally in your browser – nothing is uploaded.
What is a Unix timestamp?
A Unix timestamp (also called epoch time or POSIX time) counts the seconds elapsed since 1 January 1970, 00:00:00 UTC – the so-called Unix epoch. Because it is a single integer, the value is independent of time zone, daylight saving time, calendar format and language. That is exactly why databases, log files, APIs and file systems almost always store points in time this way and only convert to a readable date on output.
One detail that is easy to miss: Unix time ignores leap seconds. Every day counts exactly 86,400 seconds, even when the Earth's rotation occasionally calls for an extra one. Strictly speaking the timestamp therefore does not measure elapsed physical time but an idealised count of days – which is precisely the behaviour you want in everyday applications.
Seconds, milliseconds, microseconds or nanoseconds?
The very same number means a completely different date depending on the unit. Since the unit can be read off the number of digits, this tool detects it automatically – and tells you what it decided on:
| Unit | Digits today | Typical for |
|---|---|---|
| Seconds | 10 | Unix/POSIX, date +%s, JWT claims, cron, PHP time() |
| Milliseconds | 13 | JavaScript Date.now(), Java currentTimeMillis(), Kafka |
| Microseconds | 16 | Python time.time_ns()/1000, PostgreSQL internals, ClickHouse |
| Nanoseconds | 19 | Go UnixNano(), InfluxDB, Prometheus internals, tracing |
The classic mistake: a millisecond value read as seconds, which lands you in the year 56,000 – or a second value read as milliseconds, showing 20 January 1970. Whenever a date looks implausible, the unit is almost always the culprit. The dropdown lets you override the automatic detection at any time.
ISO 8601 and RFC 3339
2026-09-04T14:30:00+02:00 is the notation used by practically every modern API.ISO 8601 is the underlying standard, RFC 3339 a stricter reading of it for use on the internet: it mandates the T separator, always requires an offset and disallows the more exotic ISO variants such as week dates (2026-W36-5) or truncated forms. Every RFC 3339 date is therefore also a valid ISO 8601 date, but not the other way round.
The trailing Z (2026-09-04T12:30:00Z) means offset zero, i.e. UTC – pronounced “Zulu”, after the NATO phonetic alphabet. What matters is the difference between anoffset and a time zone: +02:00 is just a number valid for one specific moment, while Europe/Berlin is a zone with an entire history of transition rules. You cannot reconstruct the zone from the offset alone.
The year 2038 problem
If a timestamp is stored as a signed 32-bit integer, it stops at2,147,483,647 – which corresponds to 19 January 2038, 03:14:07 UTC. One second later the value flips negative and the system ends up in December 1901. Mostly affected are older embedded systems, legacy file formats and 32-bit builds; on 64-bit systems the range covers roughly 292 billion years. If you still store time_t as anint, now is a good time to check.
Negative timestamps and dates before 1970
Dates before the epoch are represented as negative numbers: -86400 is 31 December 1969. That works fully here, but it is not a given everywhere – some databases and libraries reject negative values or read them as unsigned, which produces dates in the year 2106. For historical dates, also keep in mind that the IANA time zone database only has reliable offsets for many regions from the late 19th century onwards.
Frequently asked questions
Which time zone are the dates shown in?
The one selected above. It defaults to your browser's zone, and UTC plus every zone of the IANA database are available. The conversion honours the daylight saving rules in effect at that particular moment – a date in January is therefore converted differently from one in July.
Why is my result off by one or two hours?
Almost always because a value was stored as local time but read as UTC (or the other way round). The timestamp itself has no time zone – the zone only enters the picture when it is displayed. So check which zone the value was created in.
What does the week number in the result list mean?
The ISO 8601 week number: weeks start on Monday, and week 1 is the week containing the first Thursday of the year. That is why 31 December can already fall into week 1 of the following year – which is why the matching year is shown alongside it.
Is anything I type uploaded?
No. The entire conversion is JavaScript running in your browser, and the time zone data ships with the browser itself. There is no server that could receive anything. The only things remembered are the selected direction, unit and time zone.
Related: the JWT decoder renders theexp, iat and nbf claims as readable dates, and thecron generator computes the next run times of a schedule.