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.

Unix Timestamp Converter (Any Time Zone)

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.

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.