Unix Epoch Converter
Timestamps to dates and back, in seconds or milliseconds.
Runs entirely in your browser
Loading the tool…
Current Unix time: …
—
| Relative | — |
|---|---|
| Your local time | — |
| UTC | — |
| ISO 8601 | — |
| RFC 2822 | — |
| Readable | — |
| Seconds | — |
| Milliseconds | — |
| Day of year | — |
| ISO week | — |
| Leap year | — |
Unix time counts the seconds since 1 January 1970 UTC, ignoring leap seconds.
It is the timestamp in your database rows, your log lines and your JWT
exp claims. Ten digits means seconds; thirteen means milliseconds, and
this converter detects which you pasted.
Dates come back in UTC, in your local offset, as ISO 8601 and RFC 2822, plus a relative phrase like "3 days ago", which is usually the one that answers the question you actually had.
Pick a direction at the top and there is one box to fill in: a timestamp going one way, a date going the other. Switching direction carries the moment across, so going back and forth on the same instant does not mean typing it again.
How to use it
- Choose which way you are converting.
- Paste the timestamp, or the date, and read the answer as you type.
- Copy whichever format you need from the table.
Questions
Seconds or milliseconds: which do I have?
Ten digits is seconds (the Unix convention); thirteen is milliseconds (the JavaScript convention, from Date.now()). This page auto-detects, but check the returned year looks plausible.
What is the Year 2038 problem?
A signed 32-bit timestamp overflows on 19 January 2038. Anything storing time in a 32-bit int breaks then. 64-bit timestamps push the limit past the lifetime of the sun.
Why does my local time differ from UTC by an odd amount?
Not every zone is a whole hour from UTC. India is +5:30, Nepal +5:45, Chatham Island +12:45. The local row uses your device's current offset, daylight saving included.
Does Unix time count leap seconds?
No. It defines every day as exactly 86400 seconds, so when a leap second is inserted the counter either repeats a value or is smeared across the day, depending on whose servers you are on. That makes arithmetic simple and makes precise timing across a leap second impossible. There have been 27 of them, none since 2016.
Why does my timestamp have 16 or 19 digits?
More precision. Ten digits is seconds, thirteen is milliseconds, sixteen is microseconds and nineteen is nanoseconds. Postgres and Python lean toward microseconds, Go and Rust often hand you nanoseconds. Divide down to seconds before comparing two that came from different systems.
Can a timestamp store a time zone?
It cannot, and treating it as though it can is the most common date bug there is. A Unix timestamp is a moment in time with no location attached. If it matters where the clock was, store an IANA zone name such as Europe/Lisbon next to it, not a fixed offset, because the offset changes twice a year and the rules themselves change every few years.
What is the difference between ISO 8601 and RFC 3339?
RFC 3339 is a tightened profile of ISO 8601 for internet protocols: it insists on a four-digit year, the T separator and an explicit offset, and it drops the exotic forms ISO allows, such as week dates and missing separators. Every RFC 3339 timestamp is valid ISO 8601; the reverse is not true, which is why some parsers reject a date another tool happily produced.
Timestamps worth recognising
| Timestamp | UTC | Why it is remembered |
|---|---|---|
0 | 1 Jan 1970, 00:00:00 | The epoch itself, a Thursday |
1000000000 | 9 Sep 2001, 01:46:40 | The first billion, watched live by a lot of engineers |
1234567890 | 13 Feb 2009, 23:31:30 | The digits in order, and a running joke ever since |
1500000000 | 14 Jul 2017, 02:40:00 | A round number, useful as a test fixture |
2000000000 | 18 May 2033, 03:33:20 | The second billion, still ahead of us |
2147483647 | 19 Jan 2038, 03:14:07 | The last second a signed 32-bit integer can hold |
Other systems count from other days
Unix time is the common one, not the only one, and mixing two of them up produces dates that are wrong by decades rather than obviously broken:
| System | Counts from | In units of |
|---|---|---|
| Unix | 1 Jan 1970 | Seconds |
JavaScript Date.now() | 1 Jan 1970 | Milliseconds |
| Windows FILETIME | 1 Jan 1601 | 100-nanosecond ticks |
.NET DateTime.Ticks | 1 Jan 0001 | 100-nanosecond ticks |
| Excel serial dates | 0 Jan 1900 | Days, with a deliberate leap-year bug |
| Classic Mac OS | 1 Jan 1904 | Seconds |
| GPS time | 6 Jan 1980 | Seconds, ignoring leap seconds |
Excel is the entertaining one. It treats 1900 as a leap year because Lotus 1-2-3 did, and Microsoft kept the bug for compatibility, so every Excel date before March 1900 is off by a day and every one after it silently carries the extra day forward. GPS is the practical one: it has skipped no leap seconds since 1980 and now runs 18 seconds ahead of UTC.
One direction each
The two directions have a page each, opening on the one they are named after rather than on a toggle you have to find:
Your data stays on your device
Everything above runs inside your browser as WebAssembly compiled from Rust. Nothing you type is uploaded, logged or stored on a server. You can load this page once, go offline, and it still works.
This page makes no requests at all, to anywhere. That is not a promise in the copy: it is a Content-Security-Policy header your browser enforces, and connect-src on it is none. Open the network tab and watch nothing happen.