Date to timestamp
Convert date to timestamp.
Turning a date into a Unix timestamp
A date is ambiguous until you say which zone it is in. A timestamp is not — it is a single instant counted from 1970 UTC. Converting between them means committing to a zone, and getting that wrong shifts the answer by hours.
How it works
- Interprets the date and time you supply in a chosen zone, then counts the seconds since the Unix epoch.
- Reports the result in seconds and milliseconds, since different systems expect different units.
- Makes the zone explicit rather than silently assuming your browser's, which is where most conversion bugs originate.
timestamp = seconds since 1970-01-01T00:00:00Z the same wall-clock time in two zones gives two different timestamps, separated by the difference in their offsets milliseconds = seconds × 1000
Worked example
15:00 on 20 March 2026, interpreted first as UTC and then as Warsaw local time.
- 2026-03-20T15:00:00Z → 1774018800
- in milliseconds → 1774018800000
- 2026-03-20T15:00:00+01:00 (Warsaw) → 1774015200
- the two differ by 3,600 seconds — exactly one hour
Same date, same clock reading, two timestamps an hour apart. The zone is not a formatting detail; it is part of what the date means.
Reading the result
- A bare date string like 2026-03-20 is parsed as UTC midnight by the ECMAScript specification, while 2026-03-20T00:00:00 without a Z is parsed as local. Those two differ by your offset, which is why date-only inputs are a common source of off-by-one-day bugs.
- Unix time ignores leap seconds. Every day is exactly 86,400 seconds, so a timestamp is not a true count of elapsed physical seconds — for interval measurement use a monotonic clock instead.
- Check whether the receiving system wants seconds or milliseconds. Ten digits is seconds, thirteen is milliseconds, and passing one where the other is expected produces a date in 1970 or in the year 57,000.
- For dates before 1970 the timestamp is negative. That is valid, but handling varies — some databases and libraries reject or mishandle negative values.
Common questions
- Why does my date come out a day early or late?
- Almost always a zone assumption on a date-only value. If you enter 2026-03-20 and the system reads it as UTC midnight, anyone west of Greenwich sees the nineteenth in local time. Always attach an explicit time and zone to a date you intend to convert.
- Should I store dates or timestamps?
- Store an instant, in UTC, whenever the thing you are recording happened at a moment — an event, a log entry, a transaction. Store a plain date only when the zone genuinely does not matter, such as a birthday, where 20 March means the same thing everywhere.