--- title: "Unix timestamp converter" canonical: "https://devtools.nicxon.tech/tools/timestamp/" source: "https://devtools.nicxon.tech/tools/timestamp/" generator: devtools.nicxon.tech --- # Unix timestamp converter > Convert Unix seconds or milliseconds to a human date in any time zone, and back. ## What this does Unix time counts the seconds (or milliseconds) since 1970-01-01T00:00:00Z. This tool converts a Unix number to a full set of readable forms, and parses a calendar date back into Unix seconds and milliseconds. Time-zone maths uses the browser's `Intl.DateTimeFormat` with the IANA database, so historical offset changes and daylight-saving rules for the selected zone are applied correctly. No network calls — the conversion and the zone data both come from your browser. ## When you'd use it - Making sense of a timestamp in a log line, a database row, or a JWT's `exp` claim. - Producing a Unix value to paste into a query or a config that expects one. - Checking what "now" is in epoch form for a quick test. - Working out whether an `iat`/`exp` pair is minutes or hours apart. - Converting a meeting time in one zone to UTC for a cron schedule. ## Worked example Enter `1700000000` with the zone set to UTC: ``` Unix seconds 1700000000 Unix milliseconds 1700000000000 ISO 8601 (UTC) 2023-11-14T22:13:20.000Z Local to UTC Tuesday, 14 November 2023 at 22:13:20 UTC RFC / UTC string Tue, 14 Nov 2023 22:13:20 GMT Relative (depends on today) ``` Switch the zone to `Africa/Nairobi` and the "Local" row becomes `15 November 2023 at 01:13:20 GMT+3` — same instant, next calendar day. Now type `2023-11-15 01:13:20` into the date box with the zone still on Nairobi and the left box reads `1700000000` again, confirming the round trip. Change the zone to UTC without changing the text and the timestamp shifts by three hours, because the same wall-clock string now denotes a different instant. ## Limits and gotchas - **Timestamps carry no zone.** The zone selector controls interpretation of typed dates and the display of results, not the underlying instant. - **Unit detection is heuristic.** Override it by adjusting the digit count when a value sits near a boundary. - **Ambiguous local times.** During a DST "spring forward" gap or "fall back" overlap, a wall-clock string can map to no instant or two; the tool picks one. - **Browser zone data.** Results depend on the IANA data shipped with your browser; a very old browser may have stale rules for some zones. - **Not a duration calculator.** It converts single instants, not intervals between them. ## How to use - **Enter a timestamp or a date** — Type a Unix number in the left box, or a date string in the right box. The other side updates. - **Set the time zone** — Pick the IANA zone the date should be read in or displayed in. UTC is the default. - **Read every representation** — The table shows Unix seconds and milliseconds, ISO 8601 UTC, the local time in your zone, an RFC string, and a relative phrase. - **Copy the ISO value** — Use the copy button for the ISO 8601 string, which is the safest format to store or transmit. ## Frequently asked questions ### Is my number in seconds or milliseconds? This tool guesses by length: about 10 digits is seconds, about 13 is milliseconds, about 16 is microseconds. A 10-digit value lands in 2001–2286; a 13-digit value that you treat as seconds would land tens of thousands of years in the future, which is the tell. If your number is near a boundary, set it explicitly by adding or removing three zeros. ### Why does the same timestamp show a different date for someone else? A Unix timestamp is an absolute instant — it has no time zone. The calendar date it corresponds to depends on the zone you view it in. 1700000000 is 2023-11-14 22:13:20 in UTC, but 2023-11-15 in Nairobi and still 2023-11-14 in New York. Always record which zone a displayed date was in. ### I entered "2023-11-14 22:13" and got an unexpected instant. A date string with no offset is ambiguous. This tool resolves it in the zone you selected. If you paste a string that does carry an offset or a trailing Z, that wins and the zone selector only affects the display. Mixing the two is the usual cause of a one-to-twelve-hour error. ### Does it handle dates before 1970 or leap seconds? Negative timestamps (before 1970) work. Leap seconds do not exist in Unix time — the count is defined as seconds since the epoch ignoring leap seconds, so 23:59:60 UTC on a leap-second day is not representable, same as in every mainstream language runtime. --- *Source: [https://devtools.nicxon.tech/tools/timestamp/](https://devtools.nicxon.tech/tools/timestamp/) — generated by devtools.nicxon.tech.*