Date to Epoch Converter
Type a date and read its Unix timestamp, in seconds and 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 | — |
Type a date and read its timestamp. The box opens on the current moment, and takes
2024-03-17 14:30:00, 03/17/2024 or a full ISO 8601 string
with an offset on the end.
A date on its own is ambiguous and this page resolves it in your local
timezone. Midnight on 17 March is a different instant in London and in
Tokyo, nine hours apart, so the same text produces two different numbers. If you mean
UTC and are not sitting in it, put the offset in the string, as
2024-03-17T14:30:00Z, and the guessing stops.
The hour that daylight saving repeats is the other trap. When the clocks go back, one local hour happens twice, and a time inside it maps to two possible instants with no way to tell which was meant. A written offset is the only thing that removes the ambiguity, which is the reason logs are kept in UTC.
Both seconds and milliseconds are shown, since which one a system wants is not something the date can tell you. To read a timestamp rather than write one, use epoch to date.
How to use it
- Type or paste the value, which converts as you type.
- Read the headline answer, and the table below it for every other form.
- Press Use now for the current moment, or the other button to swap direction.
Questions
Which timezone does my date get converted in?
Your own, the one this device is set to, unless the text you type carries an offset. That matters more than it looks: the same date and time is a different instant in every zone, so a colleague running the same conversion elsewhere gets a different number for the same words.
How do I convert a date as UTC instead?
Write the offset into the string: 2024-03-17T14:30:00Z, or +00:00 for the same thing. An explicit offset overrides the local guess. Without one there is nothing in the text saying which zone was meant, and something has to assume.
Should I use seconds or milliseconds?
Whichever the system receiving it expects, and both are shown here. Unix tools, Postgres and Go work in seconds; JavaScript, Java and most JSON APIs use milliseconds. Sending one where the other is expected fails loudly by about fifty thousand years, so it tends to be caught quickly.
What happens to a time in the hour the clocks go back?
It is genuinely ambiguous: that local hour occurs twice, so the text matches two different instants and nothing in it says which. The conversion picks one. Where it matters, write the offset in the string, which is the reason systems that care keep their logs in UTC and convert only for display.
Why does Unix time start in 1970?
Because that is when it was chosen, not because anything happened. The first Unix systems needed an origin close enough that a 32-bit count would cover a useful span, and 1 January 1970 was the round date nearest to hand. Everything since has kept it for compatibility rather than for meaning.
Is my data sent anywhere?
No. The conversion runs in WebAssembly in this tab and the page makes no request of its own, so a timestamp out of a production log stays where you pasted it. Disconnect first and everything on this page still works.
The other direction
The same converter, opened the other way round. The toggle on either page still switches between them.
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.