A Unix timestamp identifies an instant as an offset from the epoch, but the bare digits do not announce whether they count seconds or milliseconds. A date-time string adds another risk: without Z or an explicit offset, the same clock reading can refer to different instants. Reliable conversion makes both choices visible and tests boundary cases instead of relying on a plausible-looking date.
This guide follows one half-second before the epoch through the Unix timestamp converter. The fixed example proves how negative values, fractional seconds, UTC, offsets, and local display interact. It is particularly useful when checking token expiry fields, log events, or API payloads.
Identify an instant, a unit, and a display zone
The Unix epoch is 1970-01-01T00:00:00Z. A seconds timestamp of 0 and a milliseconds timestamp of 0 identify that same instant. Away from zero, the unit matters: 1000 means sixteen minutes and forty seconds after the epoch in seconds, but only one second after it in milliseconds. The converter never guesses the unit from digit count because short historical values and future values make that heuristic unreliable.
UTC ISO output describes the instant consistently. Local output represents the same instant using the browser’s detected time zone and shows that zone. A different wall-clock hour does not mean the timestamp changed. It means the display used a different offset. Store or compare the instant first; localize only for people who need a regional reading.
A boundary example before 1970
Use this exact ISO value:
1969-12-31T23:59:59.500Z
Converting it to milliseconds produces -500. Converting it to whole seconds produces -1, because the tool floors toward negative infinity. Truncating toward zero would produce 0 and incorrectly place a pre-epoch instant at the epoch. This difference matters only when the ISO input includes a fractional second that cannot be represented by a whole-second result.
Use a second fixed check for offsets:
1970-01-01T01:00:00+01:00
It converts to 0 seconds and 0 milliseconds. The written clock is 01:00, but the +01:00 offset says that this is midnight UTC. Both examples describe an instant without relying on the machine’s local time zone.
Convert in both directions
Open the localized tool and select ISO-to-timestamp. Paste 1969-12-31T23:59:59.500Z, choose milliseconds, and require -500. Switch the result unit to seconds and require -1. Copy each result separately so the selected unit remains part of your notes.
Next paste 1970-01-01T01:00:00+01:00. Verify zero in both units. Then switch to timestamp-to-date, enter -500, and explicitly choose milliseconds. The UTC result must return 1969-12-31T23:59:59.500Z. Inspect the local representation and its displayed zone; its calendar date may differ, but it must represent the same instant.
Use the “Now” button only to capture a current comparison at the moment you press it. It is not a server clock and does not update continuously during rendering. For debugging, record the copied numeric value, unit, UTC ISO result, and local zone together. Never paste a milliseconds value into a seconds field merely to see whether the date looks reasonable.
Why strict ISO and negative flooring matter
The accepted inverse input includes a complete date and time with either Z or an explicit numeric offset. The tool rejects an ambiguous local form such as 2026-09-17T10:00:00 because no offset identifies the instant. It also validates calendar components before constructing a date, so 2026-02-30T00:00:00Z is an error rather than a silently normalized March date.
ECMAScript represents time values as milliseconds relative to the epoch and defines a finite range for Date. The tool additionally requires safe integer timestamp input and checks the range before formatting. The source field is limited to 100 characters. These validations produce a specific failure rather than an “Invalid Date” that hides whether the problem was syntax, unit, precision, or range.
Flooring is the mathematical mapping from a fractional instant to the containing whole second. For positive 500 milliseconds after the epoch, floor gives 0; for 500 milliseconds before it, represented as -0.5 seconds, floor gives -1. This preserves ordering around the epoch and matches the documented contract.
Diagnose dates that look wrong
A date near 1970 or far in the future often indicates the wrong unit. Stop and check the source contract. Do not multiply or divide by 1,000 until you know whether the field is seconds or milliseconds. APIs sometimes use both in different properties.
An invalid-date error can indicate missing Z or offset, an impossible day, or unsupported syntax. Supply a full form such as 2026-09-17T10:00:00Z or 2026-09-17T12:00:00+02:00. A date-only string or a regional string such as 17/09/2026 10:00 does not define a unique instant for this converter.
An unsafe-integer or out-of-range error means the numeric value cannot be handled exactly or represented by the date model. Keep the original as text and consult its producer. Rounding it until it passes can create a different instant. If local time is unexpected, inspect the shown zone and UTC value before changing the timestamp.
Use timestamps safely in real workflows
For token expiry, compare compatible numeric units and document whether the boundary is inclusive. Decoding an expiry field does not verify a token’s signature or authorization. For logs, retain UTC and the original timestamp; add local display as presentation metadata. For database imports, use a column type whose precision matches the source.
Offsets describe the relationship to UTC at that instant. They are not a full time-zone rule. +02:00 does not identify Europe/Madrid and cannot tell you future daylight-saving transitions. When scheduling local civil time, store an IANA zone separately and use a scheduler designed for it.
The conversion runs in the browser and does not require uploading the entered value. Still avoid using screenshots of production tokens or logs in examples. Replace identifiers and payloads with synthetic data, and record only the fields needed for diagnosis.
Limits of the converter
The tool converts integers in explicitly selected seconds or milliseconds and strict ISO date-times with Z or an offset. It does not infer units, parse informal regional dates, model leap seconds, preserve sub-millisecond precision, or resolve time-zone names from offsets. Whole-second output discards fractional milliseconds by flooring, including for negative instants.
Local formatting depends on the browser environment and its time-zone database. It is a display aid, not proof of a jurisdiction’s historical rule. Conversion also cannot establish that a timestamp is trustworthy, current, signed, or semantically the right field. Validate those properties in the source protocol.
Final timestamp checklist
Name the source field and its documented unit. Preserve the original text. Test 0, a known production-adjacent value, and the negative fixture where relevant. For ISO input, require a real calendar date plus Z or explicit offset. Verify UTC before local display and record the detected zone.
For this guide’s fixture, require -500 milliseconds and -1 seconds for 1969-12-31T23:59:59.500Z; require zero for 1970-01-01T01:00:00+01:00; and reject 2026-02-30T00:00:00Z. Copy values with their units, then compare them only with values expressed in the same unit.
Sources: ECMAScript specification: Date Objects, ECMAScript date time string format, and RFC 3339: Date and Time on the Internet.