Convert a date to a Unix timestamp

Turning a date into a timestamp

A Unix timestamp is a single integer: the number of seconds since midnight UTC on 1 January 1970. Going from a timestamp to a date is mechanical — the number already names the instant, and the timestamp-to-date converter just formats it. Going the other way, from a calendar date to a timestamp, has one genuine decision hiding in it, and it is the source of nearly every off-by-a-few-hours bug in date handling.

The decision is which clock the date is read on. The six numbers 2026-01-01 00:00:00 are not an instant on their own. Read as UTC they are one moment; read on a wall clock in Los Angeles they are eight hours later; read in Tokyo, nine hours earlier. Until you fix the timezone, a date is a description of a clock face, not a point in time — so this converter asks you to choose. Pick UTC for anything you will store in a database, put in a log, or send to another system: it has no offset and no daylight saving, so it means the same thing everywhere. Pick local time when the date came off a clock in front of you and you want the instant a person in your timezone experienced.

The unit trap, in reverse

Once the instant is fixed, the only remaining question is precision, and the same instant is written four different ways depending on what the target expects:

• 1767225600 — 10 digits, seconds. Unix tools, most APIs, Postgres, Go's Unix().
• 1767225600000 — 13 digits, milliseconds. JavaScript's Date.now(), Java's currentTimeMillis().
• 1767225600000000 — 16 digits, microseconds. Postgres internal time, many tracing systems.
• 1767225600000000000 — 19 digits, nanoseconds. Go's UnixNano(), most metrics pipelines.

Hand a seconds value to something that wanted milliseconds and your date lands three weeks after the epoch, in January 1970; hand milliseconds to something expecting seconds and it lands in the year 58,000. The nanosecond value deserves particular care: at 19 digits it is already past the range a JavaScript Number can hold exactly, so this page computes the micro- and nanosecond forms with BigInt and gives them to you as exact strings. Never store a nanosecond timestamp in a floating-point double.

The daylight-saving gap

There is one class of local time that does not exist. On the spring-forward morning, clocks skip an hour — in most of the United States, 02:00 becomes 03:00 instantly — and every wall-clock reading in the skipped hour never happens. Ask this tool to interpret 02:30 on such a date as local time and it does not reject you: following the ECMAScript rule, it resolves the reading using the UTC offset that was in force just before the jump, which places it at the instant that reads back as 03:30. The result notes that the time was shifted, so the discrepancy is visible instead of silent. Interpreting the same fields as UTC sidesteps the whole thing, because UTC never springs forward.

The same conversion in code

For reference, here is how to turn 2026-01-01 00:00:00 read as UTC into a seconds timestamp in four common environments. Watch the month indexing: JavaScript counts months from zero, so January is 0, while the others count from one.

• JavaScript: Math.floor(Date.UTC(2026, 0, 1, 0, 0, 0) / 1000)
• Python: int(datetime(2026, 1, 1, tzinfo=timezone.utc).timestamp())
• PostgreSQL: extract(epoch from timestamptz '2026-01-01 00:00:00+00')::bigint
• Go: time.Date(2026, 1, 1, 0, 0, 0, 0, time.UTC).Unix()

For local time instead, drop the tzinfo in Python, swap time.UTC for time.Local in Go, use timestamp without the offset in Postgres, and use new Date(2026, 0, 1).getTime() in JavaScript — each of which then depends on the machine's configured zone, which is exactly the ambiguity this page makes explicit.

Common questions

Midnight on a date — but whose midnight?

A calendar date is not an instant until you say which clock it is read on. "1 January 2026, 00:00" is a different moment in Tokyo than in New York, and different again in UTC — the same six numbers, up to a full day apart. That is the whole ambiguity of turning a date into a timestamp, so this converter makes you choose: interpret the fields as your local timezone, or as UTC. UTC is the safe default for anything stored or sent between systems, because it has no offset and no daylight saving; local is what you want when the date came off a wall clock in front of you.

What happens when the time I enter never existed?

On the morning a region springs forward for daylight saving, the clock jumps straight from 01:59 to 03:00, and every wall-clock time in that gap — 02:30, say — simply never occurs. When you interpret such a time as local, this tool does not error: it resolves it the way ECMAScript does, using the UTC offset that was in force just before the transition, so 02:30 lands on the instant that reads back as 03:30. The result row flags that it was shifted rather than pretending the input was fine. Interpret the same fields as UTC and the question disappears entirely, because UTC has no transitions.

Why are the nanoseconds shown as plain text I can only copy?

A nanosecond timestamp for any present-day date is 19 digits, and JavaScript's Number can only hold about 16 significant digits exactly — past Number.MAX_SAFE_INTEGER the last few digits round silently, so 1784563200000000000 might come back as ...000512. This converter computes the micro- and nanosecond values with BigInt and hands them to you as strings, so every digit is exact. That is also why you should never do nanosecond arithmetic in a double; use a 64-bit integer or a big-integer type.

Does my language want seconds or milliseconds?

It depends on the platform, and mixing them up is the most common timestamp bug there is. Unix tools, most REST APIs, Postgres's to_timestamp, and Go's Unix() all speak seconds. JavaScript's Date.now() and Java's System.currentTimeMillis() speak milliseconds. When you feed a seconds value to something expecting milliseconds it reads as three weeks after 1970; the reverse lands you tens of thousands of years in the future. This page gives you all four units at once so you can pick the one your target actually wants.

How do I produce this same timestamp in code?

For a UTC reading of 2026-01-01 00:00:00: JavaScript, Math.floor(Date.UTC(2026,0,1,0,0,0)/1000); Python, int(datetime(2026,1,1,tzinfo=timezone.utc).timestamp()); PostgreSQL, extract(epoch from timestamptz '2026-01-01 00:00:00+00')::bigint; Go, time.Date(2026,1,1,0,0,0,0,time.UTC).Unix(). Note the month indexing trap — JavaScript months are 0-based, so January is 0, while every other language here uses 1. Swap time.UTC for time.Local, or drop the tzinfo, to read the same fields as local time instead.

Does anything I type get uploaded?

No. The conversion runs entirely in your browser using built-in date functions and BigInt. Nothing is sent to a server, logged, or stored, and the page keeps working offline once loaded.