You paste a timestamp into a converter and get a date decades away from the one you expected. Often the number is valid; the unit is wrong. A Unix timestamp converter can only show the right instant if it knows whether the input counts seconds or milliseconds since the Unix epoch.
The Unix epoch begins at January 1, 1970, 00:00:00 UTC. Many systems store elapsed seconds from that starting point. JavaScript's Date values, however, use milliseconds. A millisecond is one-thousandth of a second, so mixing the two scales produces a very different date.
Consider 1700000000 in seconds. It identifies November 14, 2023, at 22:13:20 UTC. The same instant expressed in milliseconds is 1700000000000. The millisecond number is 1,000 times larger because it counts smaller units.
That explains two common failures. If a seconds value is treated as milliseconds, it lands near the beginning of 1970. If a milliseconds value is treated as seconds, it becomes far too large for an ordinary contemporary date and may be outside the range accepted by the tool or programming language.
Current-era seconds values are often about ten digits, while milliseconds values are often about thirteen. That is a useful initial clue, not a universal rule. Negative timestamps, values for older dates, fractions of a second, and data exported in another unit can all break a simple digit-count test. Some systems also use microseconds or nanoseconds.
For reliable conversion, look at the source documentation or field name. Names such as created_at_ms strongly suggest milliseconds, while an API specification may explicitly say "seconds since epoch." If neither is available, test both interpretations and compare the result with a known event, then confirm the unit before using it in a report or calculation.
Be wary of copying a value from a spreadsheet cell that has rounded a long number or displayed it in scientific notation. A missing final digit can shift a millisecond timestamp by a second or more. Preserve the original text or full numeric precision when transferring timestamps between tools.
In JavaScript, Date.now() returns the current epoch value in milliseconds. Likewise, new Date(...).getTime() returns milliseconds. If an API gives your code a Unix timestamp in seconds, multiply it by 1,000 before constructing a JavaScript Date from that number. If you need seconds from a millisecond value, divide by 1,000 and decide whether to preserve a fractional part or round it according to your use case.
Do not silently round a timestamp when precise timing matters. A value with fractional seconds may contain information you want to keep. For an ordinary calendar display, whole seconds may be enough; for timing or event ordering, they may not be.
Open Epochly's timestamp converter when a value does not look right. Confirm the input unit, read the UTC result, and then view the time in the zone that matters to your task. You can test 1700000000 and 1700000000000 as a pair: when interpreted in their respective units, they should resolve to the same moment.
The key question is not "How many digits does this timestamp have?" It is "What unit did the source intend?" Answer that first, and a Unix timestamp converter becomes a dependable way to read the date.
