Timestamp Converter

Convert between Unix timestamps and human-readable dates.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Unix time is how most systems store a moment and how few humans read one, so this translates a timestamp into a date and back, showing your local time and UTC side by side to remove any doubt about which you are looking at.

How to use it

1Paste a timestamp, or pick a date.
2Read the result in both your local timezone and UTC.
3Copy whichever form you need.

Example

Input: 1700000000
Output: 14 November 2023, 22:13:20 UTC

Ten digits means seconds; thirteen means milliseconds. Getting that wrong is the classic off-by-1000 bug.

What happens to your data

This tool runs entirely in your browser. Your input is never uploaded to a server, never stored, and never logged. Your timezone is read from the browser's own clock settings and never reported anywhere; switch machines and you may see a different local time for the same value.

Last updated August 2026

Convert between Unix timestamps and human-readable dates in both directions. Unix time — the number of seconds (or milliseconds) since 1 January 1970 UTC — is how most systems store time, but it's unreadable at a glance. This tool translates a timestamp into a date and a date back into a timestamp instantly.

It answers the constant debugging question: *what actual date and time does this number represent?*

Work out which direction you are in before you paste, because the two are not equally safe. A number to a date is unambiguous: the timestamp names one instant, and the only choice left is the zone you read it in. A date to a number is not, because the picker takes a wall-clock reading with no zone attached and interprets it in the zone your machine is set to. Convert 09:00 for a server in Frankfurt while sitting in Mumbai and you get 09:00 Mumbai time instead.

The mistake behind most of these lookups is treating the number as though it carried a zone. It does not — it is a count from one fixed instant, so a time stored in UTC and the same wall clock stored locally are different numbers, and nothing in the digits tells you which you have. When a converted date sits a whole number of hours off what a log claims, that is nearly always why.

How it works

Toolvore converts timestamps in your browser, using your local timezone and UTC side by side so there's no ambiguity. All computation is local. Both readings come from the browser's own date object, which sets a few limits. The Local line is a plain date string with no field for fractions of a second, so a 13-digit value's milliseconds appear only on the UTC line. The zone is whatever your machine reports, and cannot be overridden here. The timestamp box wants a bare integer: spaces around it are trimmed, but a decimal point, a plus sign, a thousands comma or an underscore is refused as 'Timestamp must be an integer', while a leading minus is read as a date before 1970. Past about 8.64 trillion seconds either side of the epoch you get 'Invalid timestamp'. The picker steps in whole seconds, so its millisecond output always ends in three zeros.

Common use cases

Reading timestamps in database rows, logs, and API responses
Converting a date to a Unix timestamp for a query or filter
Debugging timezone and off-by-1000 (seconds vs milliseconds) issues
Checking token or cache expiry times
Working out what a negative timestamp in older data represents

Frequently asked questions

Seconds or milliseconds?＋

Unix timestamps are usually in seconds (10 digits) but JavaScript uses milliseconds (13 digits). The tool handles both — check the digit count if a date looks wrong.

Which timezone is used?＋

Both your local timezone and UTC are shown so you can avoid confusion.

Is it private?＋

Yes — all conversion happens locally in your browser.

What happens to Unix timestamps in 2038?＋

A signed 32-bit integer runs out at 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. A system still storing time that way wraps to the negative end and reports a date in December 1901. Anything on a 64-bit integer — most current languages, kernels and databases — is fine for longer than the question is worth asking. Where it still bites is old embedded firmware, file formats with a fixed 32-bit field, and columns somebody typed as a 4-byte integer years ago. Paste 2147483647 in seconds mode to look at the ceiling directly.

Why does my timestamp have 16 or 19 digits?＋

Because it is neither seconds nor milliseconds. Sixteen digits is microseconds, the resolution Postgres timestamps and Python datetimes carry; nineteen is nanoseconds, which is what Go's UnixNano returns and what InfluxDB and OpenTelemetry store. Read a microsecond value as milliseconds and the date comes back in the year 55840, which is the tell. Nanoseconds fall outside the range of the date type altogether, so you get an error rather than a nonsense year. Divide by 1,000 for milliseconds or 1,000,000 for seconds, and accept that you are dropping the precision that made the number long in the first place.

Does Unix time account for leap seconds?＋

No, and that is a definition rather than an oversight. POSIX time treats every day as exactly 86,400 seconds, so a leap second has no number of its own — the same value is either used twice or the clock is smeared over several hours so that no value repeats. Two things follow. The difference between two timestamps is not the count of physical seconds that elapsed between them, and the running total since 1972 is 27 seconds. And 23:59:60, a legal UTC reading, cannot be written as a Unix timestamp at all. For true elapsed time you want a monotonic clock rather than wall time.

Why does my date come out a day earlier than expected?＋

Almost always a date-only string. The ECMAScript spec parses a bare '2026-08-13' as midnight UTC, but '2026-08-13T00:00:00', with a time attached and no offset, as local — the same date written two ways is two different instants, and anywhere west of Greenwich the first displays as the previous evening. The same trap sits inside date pickers that hand you a day with no time, and in code that formats an instant for a zone other than the one it was created in. If the value is genuinely a date — a birthday, an invoice date — storing it as a timestamp is the underlying mistake.

What happens to times in the hour the clocks change?＋

A local wall-clock reading is not always a real instant, and the picker deals in wall clock. In London on 29 March 2026 the hour starting 01:00 does not exist; ask for 01:30 and the browser quietly hands back 02:30 BST. On 25 October 2026 that same 01:30 happens twice, an hour apart, and only the earlier one is ever chosen — there is no way to name the second. A round trip through local time is therefore unreliable for two hours a year, which is why scheduling systems store an instant plus a zone name rather than a local string.

How do I convert a Unix timestamp in SQL or on the command line?＋

Postgres has to_timestamp(1700000000), returning a timestamptz rendered in the session's TimeZone setting; MySQL has FROM_UNIXTIME(), with UNIX_TIMESTAMP() going the other way; SQLite has datetime(1700000000, 'unixepoch'), plus 'localtime' if you want it shifted. On the shell, GNU date takes date -d @1700000000 while BSD and macOS date takes date -r 1700000000 — the flags are not interchangeable, which is the usual reason a one-liner that worked on a laptop fails on a build box. In Python, reach for datetime.fromtimestamp(ts, tz=timezone.utc), because the bare call uses whatever zone the host is set to.

What does the Z at the end of a timestamp mean?＋

Z is Zulu: a zero offset, identical in meaning to +00:00 and shorthand for a reading already in UTC. What it is not is a timezone. An offset says how far a clock sat from UTC at one moment; a timezone is the set of rules deciding what that offset will be on any given date. +01:00 could be London in July or Berlin in January, and neither string tells you which rules apply next spring. A past event is safe as a timestamp or an offset string; a future appointment needs the zone name — Europe/London — stored beside it, or the clocks change underneath the booking.