Unix Timestamp Converter

What a Unix timestamp counts, and what it quietly ignores

A Unix timestamp is one integer: the number of seconds that have passed since 1970-01-01 00:00:00 UTC. That instant is the epoch, fixed when Unix was built at Bell Labs in the early 1970s, and the count has never been rebased since. Because it is measured from a point in UTC, the number carries no time zone, no calendar, no separators and no ambiguity. 1735689600 is the same moment in London, New York and Tokyo; only the wall clock reading differs. That is why logs, API payloads, JWT claims and database columns store the integer and leave formatting to whatever is doing the displaying.

The naive way to read one back is to guess. That fails in two directions that look nothing alike. Hand a millisecond value such as 1735689600000 to something expecting seconds and the date lands in the year 56,000, which at least announces itself. Hand a seconds value to something expecting milliseconds and you get 1970-01-20, which looks almost plausible and is easy to skim past. The second failure is subtler: a timestamp printed without saying which zone rendered it is useless for correlating two systems, and an incident timeline built from mixed local times will be wrong by whole hours.

There is one more thing the count ignores. POSIX defines every day as exactly 86,400 seconds, so the 27 leap seconds inserted into UTC since 1972 are skipped rather than counted. A Unix timestamp is therefore not a true tally of elapsed SI seconds since the epoch. It is a calendar convenience that happens to look like a stopwatch.

Which unit you have, and which output you want

Two decisions cover almost every use of this page. The Unit selector says how to read the number you pasted, and the three result rows say how you want it back. Pick the unit by counting digits:

• 10 digits: seconds. The default, and what date +%s, PHP time(), Go time.Now().Unix() and JWT iat and exp claims produce. Ten digits covers September 2001 to November 2286.
• 13 digits: milliseconds. JavaScript Date.now(), Java System.currentTimeMillis(), Kotlin and most Android APIs. Switch the Unit selector before reading the result.
• 16 or 19 digits: microseconds or nanoseconds. PostgreSQL internals, Go UnixNano() and tracing systems such as OpenTelemetry. Divide by 1,000 or 1,000,000 and paste the millisecond value.

Then take the row that matches where the value is going. Local is your own device clock, labelled with the zone your browser reports, and is the one to read when you are checking whether an event lines up with something you remember. UTC is the row to quote in an incident channel or a bug report, because it is the only reading two people in different countries will agree on. ISO 8601 is the row to paste into code, a config file or a spreadsheet, since the trailing Z makes the offset explicit and every modern parser accepts it.

How to read a timestamp out of a log line

1. Copy just the number. Leading labels, trailing commas and quote marks all make it unreadable, and a fractional value such as 1735689600.482 is fine to keep: the fraction is seconds, and it is parsed.
2. Paste it into the Timestamp box and count the digits. Ten means leave Unit on seconds, thirteen means switch it to milliseconds.
3. Read the three rows. If the year looks absurd, the unit is wrong; flip the selector and look again.
4. Quote the UTC row when you write the finding down for someone else, and note the zone shown next to Local if you quote that instead. A timestamp without its zone starts the next argument.

If the value came out of a JSON body you can pretty-print the payload first with the JSON formatter, and if it came out of a bearer token the JWT decoder will show the exp claim already converted, which is usually the question you were actually asking.

How to turn a date into a timestamp for a query

1. Use the Date and time field in the second section. It is a native browser control, so it follows your operating system conventions for date order and for the 12 or 24 hour clock.
2. Remember that the value you type is read in your own time zone, not in UTC. If you want the epoch value for midnight UTC, enter the local time that corresponds to it, or convert the wall clock first with the time zone converter.
3. Copy the row you need. Seconds is what a shell command, a Postgres to_timestamp() call or a JWT claim expects; Milliseconds is what a JavaScript Date or an Android API expects.
4. For a range, convert both ends and check the difference by hand. One day is 86,400 seconds, one hour is 3,600, one week is 604,800. If the gap is not a round multiple of those and you expected it to be, a daylight saving transition probably sits inside the range.

Getting the number where it needs to go

The large number at the top of the page is the current timestamp in seconds and updates once a second. Click it to copy. The two buttons in the date section copy the seconds and millisecond values. Where the number lands next decides whether anything else needs to change:

• Into a shell: no quoting is needed, it is only digits. To seed a test fixture an hour from now, arithmetic in the shell is easier than copying twice: echo $(($(date +%s) + 3600)).
• Into SQL: paste the seconds value into to_timestamp() on PostgreSQL or FROM_UNIXTIME() on MySQL rather than into a string comparison, so the database does the conversion and the index still gets used.
• Into a spreadsheet: epoch seconds are not a date to Sheets or Excel. Convert with =A1/86400+DATE(1970,1,1), then format the cell as a date. The result is UTC, so add the offset if you need local time.
• Into a ticket or a chat message: paste the ISO 8601 row instead of the integer. Nobody reviewing the ticket in six months will convert the number, and Slack, Jira and GitHub all leave a bare integer as a bare integer.
• On a phone: press and hold the big number to select it if the tap to copy gesture is awkward, then paste with a long press in the destination field. On iOS and on Android the clipboard is shared between apps, so a timestamp copied here pastes straight into a terminal app or a note.

The same conversion in other languages and databases

Every runtime offers both directions, and the only real trap is which unit it hands back. JavaScript is the odd one out, working in milliseconds throughout:

// JavaScript: Date works in milliseconds
Date.now()                          // 1735689600000
Math.floor(Date.now() / 1000)       // 1735689600
new Date(1735689600 * 1000).toISOString()
// '2025-01-01T00:00:00.000Z'

# Python: seconds, as a float
import time
from datetime import datetime, timezone
time.time()                                       # 1735689600.482
datetime.fromtimestamp(1735689600, tz=timezone.utc)
# datetime(2025, 1, 1, 0, 0, tzinfo=timezone.utc)
int(datetime.now(timezone.utc).timestamp())       # 1735689600

• Go: time.Now().Unix() for seconds, UnixMilli() and UnixNano() for the finer units, time.Unix(sec, 0) to go back.
• Java: System.currentTimeMillis() gives milliseconds, while Instant.now().getEpochSecond() gives seconds. Mixing the two in one codebase is a common source of the factor of a thousand bug.
• PHP: time() and date('c', $ts). Ruby: Time.now.to_i and Time.at(ts). .NET: DateTimeOffset.UtcNow.ToUnixTimeSeconds().
• Shell: date +%s works on Linux and macOS. Going back does not: GNU coreutils wants date -d @1735689600, BSD and macOS want date -r 1735689600.

-- PostgreSQL
SELECT to_timestamp(1735689600);            -- timestamptz
SELECT EXTRACT(EPOCH FROM now())::bigint;

-- MySQL (renders in the session time zone)
SELECT FROM_UNIXTIME(1735689600), UNIX_TIMESTAMP();

-- SQLite
SELECT datetime(1735689600, 'unixepoch');
SELECT strftime('%s', 'now');

Two platform details are worth knowing before you design a schema. MySQL FROM_UNIXTIME() renders in the session time zone, so the same query can return different strings for two connections, and the MySQL TIMESTAMP column type is documented as ending at 2038-01-19 03:14:07 UTC, which is the 32-bit limit discussed below. In JWTs, RFC 7519 defines exp, iat and nbf as NumericDate values, meaning seconds and never milliseconds, which is why a token built with Date.now() instead of Date.now() / 1000 appears to expire some 50,000 years from now.

Limits, edge cases and what this page does not do

What leaves your browser: nothing. Every conversion runs locally through the built-in JavaScript Dateobject, and the live clock reads your own device rather than a time server. Nothing you paste is uploaded, stored or logged, so pasting a timestamp copied straight out of a production log is safe. Analytics records only that the page was viewed.

The unit is chosen by you, not detected. The Unit selector defaults to seconds and stays where you put it. If a result is thousands of years out, that is the first thing to check.

2038 is a real deadline for some systems. A signed 32-bit integer reaches its maximum at 2038-01-19 03:14:07 UTC and then wraps to December 1901. Current 64-bit runtimes are unaffected, but embedded controllers, fixed-width file formats and 32-bit database columns are not, and they are exactly the systems nobody is watching. This page uses JavaScript numbers, whose Date range runs to roughly the years -271821 and 275760, so it is not the constraint.

Local means your device, with all that implies. The local row and the date field both read the clock and zone your operating system reports. A machine with the wrong zone set, or a VPN that has changed nothing about the clock, will produce a local reading that disagrees with a colleague looking at the same integer. The UTC row never has this problem, which is the argument for quoting it.

Precision has a floor. Fractional seconds are accepted and preserved in the ISO row, but the local and UTC rows are truncated to whole seconds for readability. If you are comparing events milliseconds apart, work from the raw values rather than from the rendered strings.

Accessibility. The live timestamp is a real button, so it is reachable with the keyboard and announces itself to a screen reader, but it updates every second, and a screen reader set to announce changes will be noisy on this page. The values are laid out with tabular figures and are selectable, so magnification and copy both behave normally.