Date to Unix Timestamp
Turn a calendar date and time into an epoch value. Pick the zone the date is written in — that choice is what makes the answer unambiguous.
Date to Unix timestamp
The date above is interpreted as wall-clock time in the selected zone, including any daylight saving offset in effect on that date.
| Seconds | — |
|---|---|
| Milliseconds | — |
| Microseconds | — |
| Nanoseconds | — |
Why the time zone field is not optional
A timestamp identifies an instant; a written date identifies a reading on somebody's clock. Those are different kinds of thing, and converting between them requires knowing whose clock you meant.
"10 March 2024, 09:00" is 1710040800 in London,
1710060600 in Kolkata and 1710079200 in Los Angeles.
All three are correct; they are simply three different moments. Software that
omits the zone is not being simple, it is picking one for you silently —
usually the server's, which is rarely what the user meant.
The two hours a year that break things
Daylight saving transitions create two genuinely awkward cases, and they are worth understanding because they cause real outages:
- The missing hour. When clocks spring forward, local time jumps from 01:59:59 straight to 03:00:00. Any wall-clock time inside the skipped hour never happens. A nightly job scheduled for 02:30 local time simply does not run that day.
- The repeated hour. When clocks fall back, 01:00–01:59 occurs twice. A job scheduled for 01:30 local runs twice, which is how duplicate invoices and double-charged customers happen.
The durable fix is to schedule recurring work in UTC and convert to local only for display. More detail in the guide to daylight saving bugs.
Picking a storage unit
Seconds are compact and sufficient for most business data. Milliseconds are
the practical default for anything user-facing, since JavaScript works in
them natively. Microseconds and nanoseconds matter for tracing and metrics,
where events land inside the same millisecond and ordering still has to be
preserved. Whichever you choose, write the unit into the column name —
created_at_ms costs nothing and prevents the single most common
timestamp bug.
Related tools
Frequently asked questions
How do I turn a date into a Unix timestamp?
Pick the date and time above, then choose the time zone that the date is written in. The tool returns the epoch value in seconds, milliseconds, microseconds and nanoseconds at once.
Why does the time zone I pick change the timestamp?
Because "9 a.m. on 10 March" is not a single instant — it happens at a different moment in Tokyo than in New York. The timestamp is a fixed point on the universal timeline, so the tool needs to know which local clock you meant before it can compute one.
What happens if I enter a time that does not exist?
When clocks spring forward, an hour is skipped — 02:30 simply never occurs on that date in that zone. The converter resolves such a time to the instant immediately after the transition rather than failing, which matches the behaviour of most date libraries.
What about times that occur twice?
When clocks fall back, an hour repeats, so a wall-clock time like 01:30 is genuinely ambiguous. The converter resolves the ambiguity to the first (daylight saving) occurrence. If the distinction matters, work in UTC instead.
Should I store dates as timestamps or as strings?
Store the instant as a 64-bit integer timestamp or a timezone-aware timestamp column, and store the intended time zone separately if you need to reconstruct what the user saw. Storing a formatted local string alone loses information you cannot recover.