Timestamps to dates, dates to timestamps, in any zone
A Unix timestamp is a count of seconds since 1 January 1970 in UTC, and most conversion pain comes from three confusions this page is built to end: seconds versus milliseconds versus microseconds, UTC versus a local zone, and wall times that daylight saving makes ambiguous or nonexistent. Enter a timestamp in any of the three units, including negative values from before the epoch, and read it in UTC and in your chosen zone; or enter a date and time as read on a clock in a zone and get the exact timestamp, with gap and overlap times handled by stated rules rather than silently.
Right now
Timestamp to date
Date to timestamp
Disclaimer: This calculator gives estimates for general information only. It is not financial, medical or other professional advice. Conversions are exact integer arithmetic on the stated conventions; the correctness of a converted moment in business or legal records remains yours to verify against the system that produced it.
What this calculator does
It converts between Unix timestamps and calendar moments in both directions, with the three units kept distinct, negative timestamps supported through exact integer (BigInt) arithmetic so millisecond and microsecond values lose no precision in the conversion, and time zones handled through the browser’s time-zone database, the same data operating systems use. Timestamp to date shows the moment in UTC and in a chosen zone with its ISO 8601 form and a plain relative reading. Date to timestamp treats your entry as a wall-clock reading in the chosen zone and resolves it to the exact second, detecting the two daylight-saving pathologies: a spring gap time, which it refuses rather than invents, and an autumn overlap time, which it resolves to the first occurrence and flags through the UTC equivalent it prints. The live clock at the top states the current epoch second, updating every second, for the surprisingly common job of checking what “now” is in the only format logs agree on.
How to use it
- Count the digits before choosing the unit. Current timestamps are 10 digits in seconds, 13 in milliseconds, 16 in microseconds. If a value’s digit count matches one of those, that is almost certainly its unit, and choosing it deliberately beats letting any tool guess. A 13-digit value converted as seconds lands in the year 33658 or so, which is the signature of the mix-up.
- UTC is the timestamp’s native zone; everything else is a display. The same moment prints different clock readings in different zones, and the conversion here always shows UTC alongside your zone so the two can be checked against each other. When sharing a converted time, share the timestamp or the ISO form with its offset, never a bare wall time, whose zone dies in transit.
- Negative timestamps are ordinary history. Anything before 1 January 1970 is a negative count, handled here exactly, including the famous minus one: the last second of 1969. Systems differ in whether they accept negatives at all; databases and file formats with unsigned fields do not, which is a property of those systems, not of the moment.
- Gap and overlap are the honest edges of wall time. On spring-forward night, 02:30 may not exist in your zone; on autumn-back night it exists twice. This page reports the first case as an error with the reason and takes the first occurrence in the second, showing the UTC result so you can see which 02:30 was meant. Scheduling anything important inside those hours, in any tool, deserves this much suspicion.
- The relative line is a sanity check, not a result. “About 3 days ago” exists to catch gross errors (a timestamp meant to be yesterday reading as 2019), the commonest real-world failure. The exact lines above it are the conversion; the relative line is the smell test.
How it is calculated
- Timestamp to date: the entered integer is scaled to milliseconds exactly (seconds x 1,000; milliseconds as entered; microseconds divided by 1,000, discarding a sub-millisecond remainder) using arbitrary-precision integer arithmetic, then the millisecond count is rendered as a calendar moment in UTC and in the chosen zone by the platform’s time-zone database. Values beyond the representable calendar range (about 275,000 years either way) are reported as out of range rather than rendered wrongly.
- Date to timestamp: the wall reading is resolved in the chosen zone by computing the zone’s offset at a first approximation of the moment, correcting once, and verifying the result maps back to the entered wall time. A wall time that no instant maps to (the spring gap) fails verification and is reported. A wall time two instants map to (the autumn overlap) verifies at the first occurrence.
Worked examples
A round-ish number. Timestamp 1760000000 seconds is Thursday, 9 October 2025, 08:53:20 UTC, ISO form 2025-10-09T08:53:20.000Z, and 04:53:20 the same morning in America/New_York, which was on daylight time (UTC -4) that day. The four-hour gap between the two clock readings is the entire content of time zones: one moment, two readings, both correct.
Minus one. Timestamp -1 second is Wednesday, 31 December 1969, 23:59:59 UTC, the final second before the epoch. It is the boundary case that unsigned systems cannot hold and the quickest test of whether a converter handles negatives at all; this one does, in every unit.
A wall time to a timestamp. 13 October 2026 at 12:00:00 read in UTC is timestamp 1791892800. Read in America/New_York, where October is daylight time (UTC -4), the same wall reading is a moment four hours later in absolute terms: 1791907200. Two identical clock readings, two timestamps 14,400 seconds apart, and the zone field is the only thing that decided between them.
Reading your results
Trust the UTC line as the moment and the zone line as its local costume. If a converted timestamp disagrees with a log or a colleague, check in this order: the unit (a factor of 1,000 is the commonest discrepancy in all of computing), then the zone the other side assumed, then whether their value was rounded, floored or taken at a different precision. A mismatch of exactly 3,600 seconds is a daylight-saving disagreement; a mismatch of a round number of hours is a zone disagreement; a mismatch of 1,000x is a unit disagreement. The three signatures diagnose nearly every timestamp argument ever held.
Limitations
- Leap seconds are not in the count. Unix time pretends every day has exactly 86,400 seconds; the real UTC clock has inserted leap seconds (27 to date) that Unix time smooths over. Conversions here follow the Unix convention, as does nearly all software; astronomical-grade timing is a different discipline.
- The zone database is your browser’s. Historical zone rules (a city’s offsets in 1950) and future rule changes depend on the database version the platform carries. Conversions for exotic historical moments can differ by an hour between systems with different database vintages.
- Overlap resolution is a stated choice, not the truth. For an ambiguous wall time, the first occurrence is used. The other occurrence is a different timestamp an hour later; if the distinction matters, the source system must disambiguate, because the wall reading alone cannot.
- Microsecond precision stops at the millisecond display. Sub-millisecond detail is carried exactly in the integer arithmetic and the returned timestamp values in the date-to-timestamp direction, but rendered dates show milliseconds, the finest the platform’s date formatting supports.
Frequently asked questions
Is a Unix timestamp in seconds or milliseconds?
By definition, seconds: the count since the epoch in whole seconds. Milliseconds are a widespread implementation habit (JavaScript’s native clock counts them), and microseconds appear in some logging and database systems, which is why the same instant circulates as 10, 13 or 16 digits and why this page makes you choose the unit instead of guessing. The digit count is the tell: around now, 10 digits means seconds, 13 milliseconds, 16 microseconds.
Why does my timestamp convert to a date in 1970 or 5138?
A unit mismatch, near-certainly. A millisecond value (13 digits) read as seconds runs a thousand times too far into the future; a seconds value read as milliseconds collapses to January 1970. The conversions are each internally correct; the label was wrong. Re-run with the unit the digit count suggests, and the moment lands where you expected. This single error accounts for most “broken converter” reports everywhere, which is why the hint sits under the unit field.
What is the epoch?
1 January 1970 at 00:00:00 UTC, the zero point of Unix time, chosen by the early Unix engineers as a round recent date. Everything before it counts negative, everything after positive, and the count is of seconds (with the leap-second smoothing described in the limitations). Other systems chose other epochs, Excel and Windows among them, which is why a timestamp moved between ecosystems without conversion is meaningless, and why the epoch is stated on the page rather than assumed.
Does a timestamp include a time zone?
No, and that is its virtue. A timestamp is an absolute count; zones enter only when a human clock reading is produced from it or consumed into it. The confusion arises because the production step is invisible in most tools. Here it is a visible field in both directions, and the UTC line is always shown, so a timestamp’s meaning can be checked without knowing which zone anyone had in mind when they read it.
Related calculators
Method: exact BigInt scaling between seconds, milliseconds and microseconds about the 1970 epoch, calendar rendering and zone resolution through the platform time-zone database with round-trip verification for wall times, exactly as defined on this page. Last reviewed: 13 October 2026.