What a Unix timestamp actually is
A Unix timestamp is a count of seconds since 1 January 1970 at 00:00:00 UTC — an instant on a single, unbroken number line. It names no place and no calendar, which is exactly why two machines on opposite sides of the planet can agree on the number without agreeing on anything else.
1785326400 → 2026-07-29T12:00:00Z — ten digits are seconds, thirteen are milliseconds, nineteen are nanoseconds
Everything readable comes later. 29 July 2026, 6:00 pm is that number after a time zone and a calendar have been applied to it; change the zone and the wall clock changes while the timestamp does not. That is the one thing worth carrying away — storing a timestamp is safe, storing a local time is not. Every conversion below runs in your browser, and the page works with the network disconnected.
Formats this tool reads
Paste any of these and the shape is detected for you. Every example below names the same instant, 2026-07-29T12:00:00Z, so you can see how the same moment is spelled in each.
| Format | Example | Notes |
|---|---|---|
| Unix seconds | 1785326400 | Ten digits today. The default reading for any number below 100 000 000 000. |
| Unix milliseconds | 1785326400000 | Thirteen digits. What JavaScript's Date.now() and most log formats emit. |
| Unix nanoseconds | 1785326400000000000 | Nineteen digits — past what a JavaScript number can hold, so this tool keeps them as exact integers. |
| ISO 8601 (UTC) | 2026-07-29T12:00:00Z | The Z means UTC. Fractional seconds to nanosecond depth are kept. |
| ISO 8601 with offset | 2026-07-29T18:00:00+06:00 | An explicit offset always wins over the input zone setting. |
| ISO week and ordinal dates | 2026-W31-3 | Week dates such as 2026-W31-3 and ordinal dates such as 2026-210 both work. |
| RFC 2822 and HTTP dates | Wed, 29 Jul 2026 12:00:00 GMT | Also reads what Date.prototype.toString() prints, trailing zone name and all. |
| Dates people type | July 29, 2026 12:00 PM | Month names in any order, 12-hour clocks, and ordinals such as 29th. |
| UUID v1, v6, v7 | 019fadbe-f200-7abc-… | These versions embed their creation time. v3, v4, v5 and v8 hold none. |
| MongoDB ObjectId | 6a69eb40a1b2c3d4e5f60718 | The leading four bytes are the creation time in seconds. |
| Windows FILETIME and .NET ticks | 134298000000000000 | Both count 100-nanosecond intervals, from 1601 and from year 1. Pick the unit — their digit counts collide with nanoseconds. |
| Excel serial date | 46232.5 | Days since 30 December 1899, phantom leap day included. Pick the unit; a bare number cannot be told apart from an epoch. |
Two shapes are deliberately refused rather than guessed at. A date such as 07/08/2026 could be 7 August or 8 July, and picking one silently is how a report ends up five weeks out; write it as 2026-07-08 instead. A zone abbreviation such as IST means three different offsets depending on the country, so an abbreviation outside the small set RFC 2822 defines is treated as though no zone were given at all.
A bare eight-digit number such as 20260729 is read as an epoch, not as a compact ISO date, because that is what such a number nearly always is in a log file. Write 20260729T000000Z if you meant the date.
Time zones, offsets and daylight saving
A time zone is not an offset. Asia/Dhaka is a zone: a named region with a history of rules. +06:00 is the offset those rules produce at one particular instant. Storing the offset loses the rules, which is why every card here shows the zone and works the offset out for the moment you are looking at.
Daylight saving is why that distinction matters. New York is −05:00 in January and −04:00 in July, so an event stored as −05:00 and replayed in summer is an hour wrong. Each card here marks whether the zone is on daylight time at that instant.
Two moments each year are genuinely awkward. When clocks spring forward, an hour of wall-clock time never happens; a date written inside that hour is placed just after the jump. When clocks fall back, an hour happens twice; a date written inside it is read as the first of the two. Both choices match what other date libraries do, but if the exact hour matters, write the offset out.
The zone list here is the full IANA database, shipped as a fixed list rather than read from your browser. Browsers and servers ship slightly different versions of that database, and a picker whose options depended on which one you were on would break the moment a page rendered on a server and then came alive in a browser. If your browser's data is missing a zone you pinned, the card is left out and the tool says so.
The controls
Four settings, and only the first two change how your input is read.
| Control | What it does | Reach for it when |
|---|---|---|
| Read numbers as | Fixes the scale a plain number is read at, instead of choosing one from its magnitude. | The value is a FILETIME, .NET ticks or an Excel serial — or the automatic reading is wrong because the number is unusually small or large. |
| Input zone | Supplies a zone for input that carries none of its own, such as 2026-07-29T12:00:00 or a date you typed. | The log you are reading writes local times without an offset. It is ignored entirely when the input names its own. |
| Pinned zones | Adds up to four more cities to the board, alongside your own zone and UTC. | You are scheduling across teams, or checking what a deploy timestamp means to somebody else. |
| The live clock | Ticks the current Unix time, and drives the relative and day-count lines further down. | You want the epoch for right now. Pause it if a moving number is distracting. |
The input zone and the pinned zones do different jobs and never interact. One decides how ambiguous input is read; the other decides how the answer is displayed. Changing which cities are on the board can never change the underlying instant.
The defaults read numbers by magnitude and treat zone-less input as UTC. UTC rather than your own zone on purpose: a bare timestamp in a log file is almost always UTC, and a default that changed with whoever opened the link would make a shared URL mean two different things.
Seconds, milliseconds, and the digits in between
The same instant is written four ways depending on how much precision the system that produced it kept. Seconds is the classic Unix form; milliseconds is what most languages hand you today; microseconds turns up in databases; nanoseconds in tracing and in Go.
Telling them apart is a matter of magnitude. A ten-digit number is seconds until roughly the year 5138; the same digit count in milliseconds would put you in 1973. Because those ranges do not overlap, reading the size of the number is reliable — which is what the automatic setting does.
Nanosecond timestamps are nineteen digits, which is more than a JavaScript number can hold exactly: 1785326400123456789 becomes 1785326400123456800 the moment it is treated as a number. Every scale here is computed with exact integers instead, so the digits you paste in are the digits you get back.
The count also ignores leap seconds. A Unix day is exactly 86 400 seconds even on the rare days that were 86 401 seconds long, so the number counts nominal seconds rather than elapsed physical ones. For everything short of satellite navigation, that is the right trade.
A signed 32-bit second counter overflows on 19 January 2038, which is the Year 2038 problem. Nothing here is affected — the counts are arbitrary-precision — but a system that still stores time in a 32-bit integer is, and pasting a date past 2038 into this tool is a quick way to see what value it ought to be holding.
When you need this
Reading a log. A line says 1785326400 and you need to know whether the incident was during business hours in Dhaka or overnight in New York. Paste it, pin both cities, and read both answers at once.
Writing a fixture. You need a timestamp for a test that expires next Tuesday, or the exact millisecond value for a date somebody described in prose. Type the date, copy the scale you need.
Debugging an id. A UUID v7 or a MongoDB ObjectId carries the moment it was created, so pasting the id tells you when the row was written without opening the database.
Frequently asked questions
2026-07-29T12:00:00 is genuinely incomplete, so something has to supply the missing piece. This tool never uses your computer's own zone for that, because then the same link would mean different instants for different people.2026-07-08 or as 8 July 2026 and it will be read exactly.