A Unix timestamp represents an instant as a numeric distance from the epoch. Errors appear when an application confuses seconds with milliseconds, applies a time zone twice, or tries to store the value in a type that is too small.
Quick verification path
- Identify whether the number uses seconds or milliseconds.
- Convert it and display the UTC date first.
- Apply a local time zone only when presenting the instant to a person.
- Check the range of the destination language, database, or protocol.
- Keep a known example around the epoch for integration tests.
An instant is not its representation
1970-01-01T00:00:00Z is a textual representation of the instant whose
timestamp is 0. A local date without a zone does not necessarily identify one
instant: it may be missing or repeated during a daylight-saving transition.
Choose the input format
- A numeric timestamp: open timestamp to date and select seconds or milliseconds. The tool does not infer the unit.
- A manual date and time: open date to timestamp and select UTC or this browser’s local time. Manual input has whole-second precision.
- An ISO 8601 string: choose “Paste ISO 8601 with time zone” in date mode.
The written
Zor offset determines the instant; the manual time-zone choice does not apply. Up to three fractional digits are preserved.
For example, 2000-01-01T01:00:00.123+01:00 produces 946684800123
milliseconds. The result shows both seconds and milliseconds, plus UTC and local
representations. See the ISO 8601 conversion example
for the exact workflow and accepted format.
The guides below also cover negative values, the 32-bit limit, leap seconds and JWT time claims, separating format mistakes from limits in the receiving system.