Epoch seconds, milliseconds, microseconds or nanoseconds to a readable date and back — with time zones, ISO 8601 and RFC 2822 forms, relative time, week numbers and date arithmetic. Units are detected from the number's size.
–––A Unix timestamp is a count of seconds since 00:00:00 UTC on 1 January 1970, ignoring leap seconds. It has no time zone: 1727438400 is the same instant in Dubai, London and São Paulo, and only turns into a wall-clock time once you choose a zone. That is precisely why it is the format systems exchange — and precisely why bugs appear when one side assumes the timestamp is "local".
The most common conversion bug is a factor of a thousand. Unix, most databases and JWT claims use seconds; JavaScript's Date.now(), Java's System.currentTimeMillis() and most JSON APIs use milliseconds; some tracing systems use microseconds or nanoseconds. This tool detects the unit from the number's magnitude — a 10-digit number is seconds, 13 is milliseconds — and says which it assumed, so a value that decodes to the year 56,000 is caught immediately.
2026-09-27T12:00:00Z is the interchange form: unambiguous, sortable as a string, and parsed by every language. The trailing Z means UTC; +04:00 is an offset. A value without either is ambiguous, and JavaScript treats the date-only form 2026-09-27 as UTC but the date-time form 2026-09-27T12:00 as local — a distinction that has produced a great many off-by-a-day bugs.
Sat, 27 Sep 2026 12:00:00 GMT is the form in email headers, HTTP Date, Last-Modified and Expires headers, and cookies. HTTP requires GMT specifically. It is shown here so you can paste it straight into a cache header or compare it with what a server sent.
ISO 8601 week numbers start on Monday and week 1 is the week containing the first Thursday, which means 1 January can belong to week 52 or 53 of the previous year. The result shows the ISO week and week-year together, because reporting code that uses the calendar year with the ISO week produces wrong figures every December and January.
A signed 32-bit integer runs out at 2,147,483,647 seconds — 03:14:07 UTC on 19 January 2038. Systems that still store timestamps in 32 bits (embedded devices, old file systems, some database columns) wrap to 1901 at that moment. The converter flags any value beyond the 32-bit range. JavaScript's own Date covers ±8.64 × 1015 milliseconds, about ±273,000 years, so inputs beyond that are refused rather than silently corrupted.
Negative timestamps are valid and mean before 1970: -86400 is 31 December 1969. Not every system accepts them — MySQL's TIMESTAMP column does not — so if you store dates before 1970 in a Unix column, check the column type first.
An offset like +04:00 is a fixed number; a zone like Asia/Dubai is a set of rules that say what the offset is at any given moment, including daylight-saving changes and historical reforms. Dubai's rules are simple (permanently +04:00); Europe/London switches between +00:00 and +01:00 twice a year, and the switch dates themselves have changed over the decades. Store instants as UTC, store the zone name alongside when you need to reproduce a wall-clock time, and never store an offset thinking it is a zone. The zone table above uses the browser's own tz database through Intl.DateTimeFormat, which is how it can show the correct offset for a date years in the past.
| Language | Seconds | Milliseconds |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | Date.now() |
| Python | int(time.time()) | int(time.time() * 1000) |
| Go | time.Now().Unix() | time.Now().UnixMilli() |
| Java / Kotlin | Instant.now().getEpochSecond() | System.currentTimeMillis() |
| C# | DateTimeOffset.UtcNow.ToUnixTimeSeconds() | DateTimeOffset.UtcNow.ToUnixTimeMilliseconds() |
| PHP | time() | (int) (microtime(true) * 1000) |
| Shell | date +%s | date +%s%3N (GNU) |
| PostgreSQL | extract(epoch from now())::bigint | (extract(epoch from now()) * 1000)::bigint |
| MySQL | UNIX_TIMESTAMP() | ROUND(UNIX_TIMESTAMP(NOW(3)) * 1000) |
By its size. Current Unix time in seconds is a 10-digit number, in milliseconds 13 digits, in microseconds 16 and in nanoseconds 19. The tool picks the unit whose range contains the number and states the assumption next to the result. If a value was genuinely meant as seconds but is 13 digits long, it would represent a date tens of thousands of years away, which is almost never what anyone intended.
Usually a time zone boundary. A timestamp at 23:30 UTC on the 27th is already the 28th in Dubai and still the 27th in New York. If you were converting a date-only string, note that JavaScript and many libraries interpret "2026-09-27" as midnight UTC, which is the evening of the 26th in the Americas. Choose the zone you actually mean in the selector, and compare the UTC and zone rows in the result.
No. Unix time is defined as if every day has exactly 86,400 seconds, so a leap second is absorbed by repeating or stretching a second rather than adding a count. That keeps day arithmetic simple — a day is always 86,400 — at the cost of Unix time being 27 seconds behind the atomic TAI scale as of 2026. For almost all software this is the right trade and can be ignored.
Systems that store Unix time in a signed 32-bit integer can only count up to 2,147,483,647 seconds, which is 19 January 2038 at 03:14:07 UTC. One second later the value overflows to a large negative number, which reads as December 1901. Modern operating systems use 64-bit time, but embedded firmware, older file formats and some database schemas do not. The tool marks any timestamp beyond the 32-bit range so you can see which values would be affected.
Store the instant in UTC, using a proper timestamp type (PostgreSQL timestamptz, an integer of epoch seconds or milliseconds) rather than a string. If you need to reproduce the wall-clock time a user saw — an appointment at 9 am in their city — store the IANA zone name alongside, not the offset, because the offset for that zone may change before the date arrives. Convert to local time only at the point of display.
No. Parsing, conversion and the time-zone table are computed in the page with JavaScript's Date and Intl APIs, which carry their own time-zone database. There is no request to any server, which you can confirm in the Network tab of your browser's developer tools, or by using the page after disconnecting from the internet.