Unix timestamps: check the unit before trusting the date
A number from a log or API can convert to an implausible date. Often the cause is not a mysterious time zone but seconds being interpreted as milliseconds, or the reverse.
The number needs an explicit unit
A timestamp measures from 1970-01-01T00:00:00Z. Some systems use seconds; JavaScript Date uses milliseconds and ignores leap seconds.
Multiply seconds by 1000 for milliseconds. Digit count alone is not a reliable contract, especially near the epoch or for negative values; check what the source specifies.
References: MDN — Date timestamps, UTC and milliseconds
The zone changes the display, not the instant
The same instant can have different local clock displays without changing its timestamp. Manually adding an offset and then displaying in that zone can apply the offset twice.
This converter explicitly uses UTC and requires Z in a date input. It does not infer a zone from the interface language or your country. Use a time-zone converter when a local display is needed.
Precision and range belong to the meaning
A fraction in seconds can represent milliseconds: 1.25 seconds is not 1250 seconds. Retain the fractional part when records need finer-than-second ordering.
This tool accepts seconds with up to 3 decimal places or whole milliseconds and validates dates rather than silently correcting nonexistent days. It is not a leap-second interval meter or a substitute for a specialized timing contract.
Example: two numbers for the same instant
86400 seconds and 86400000 milliseconds both represent 1970-01-02T00:00:00.000Z. Interpreting 86400 as milliseconds instead gives 1970-01-01T00:01:26.400Z. That mismatch is not a language or calendar problem.
−0.25 seconds represents 1969-12-31T23:59:59.750Z. The sign places it before the epoch and the fractional part is retained; a negative value is not automatically an invalid date.