Epoch / Unix Timestamp Converter

Unix time, and why a bare number is ambiguous

Unix time counts the seconds elapsed since 1970-01-01T00:00:00Z, ignoring leap seconds — the definition POSIX gives the `time()` system call every Unix-like OS implements. It is the timestamp format of log lines, JWT claims, database columns, HTTP caching headers, cron bookkeeping and roughly every API that has ever had to serialize an instant, precisely because it carries no timezone, no calendar and no locale — just a count. The trouble is that the count comes in units, and the unit is never written down next to it.

The same instant is `1788998400` in seconds, `1788998400000` in milliseconds, and `1788998400000000` in microseconds. JavaScript's `Date.now()` returns milliseconds; Python's `time.time()`, PostgreSQL's `extract(epoch from …)` and Go's `Unix()` return seconds; Java's `System.currentTimeMillis()` returns milliseconds while `Instant.getEpochSecond()` returns seconds; ClickHouse and some tracing systems emit microseconds or nanoseconds. Feed a seconds value to something expecting milliseconds and you get a date in January 1970; feed a milliseconds value to something expecting seconds and you land tens of thousands of years in the future. Both failures are common, and both look like a data problem rather than a units problem until someone converts the number by hand.

That is what the Unit control on this page is for. Left on Auto it decides by magnitude and tells you what it decided, which is right almost always. Forced to Seconds or Milliseconds it shows you the other reading, which is how you confirm a suspicion: if your ten-digit number read as milliseconds lands in January 1970, you have found the bug. The report's ISO 8601 line follows RFC 3339, the internet-friendly profile of ISO 8601 that JSON APIs and HTTP headers standardise on — a trailing Z for UTC, no ambiguous two-digit years.

Every unit in the output, and where it comes from

The report gives all the forms at once rather than making you pick one, because when you are debugging a timestamp you usually need two of them — the human-readable date to know what happened, and a different numeric unit to paste into whatever asked for it.

The bugs an epoch converter actually finds

A 401 at two in the morning is the classic. Decode the bearer token with the JWT Decoder, take the `exp` claim, paste it here, and the question 'is this token expired or is the signature wrong?' is answered in one step instead of by arithmetic on a phone calculator. The `iat` and `nbf` claims fail the same way and for the same reason: a service whose clock has drifted by more than the allowed skew rejects tokens that are, by its reckoning, from the future.

The second is the units mix-up described above, which turns up most often at a system boundary — a JavaScript front end sending `Date.now()` to a backend that stores seconds, or a data import where one source column is in milliseconds and another in seconds. If half your rows say 1970 and half say the right year, that is what you are looking at, and forcing the Unit option both ways confirms it in seconds.

The third is calendar rather than numeric. The weekday, day of year and ISO week date lines exist because scheduled jobs and reports break on exactly those fields: a job that was supposed to run on a Monday fired on Sunday because someone's week starts on a different day, or a weekly report double-counted because the ISO week-numbering year at the turn of the calendar year is not the calendar year. For building and reading the schedules themselves, the Cron Expression Generator translates an expression into plain English and shows its next run times; this page is where you check what a timestamp the job produced actually means.