A Unix timestamp converts to a readable date and back. The unit is detected by magnitude, so seconds, milliseconds, microseconds and nanoseconds are all accepted, and the unit that was assumed is reported alongside the result.
A Unix timestamp counts from midnight UTC on 1 January 1970. The problem with reading one is that the same digits mean different moments depending on the unit: 1700000000 is November 2023 in seconds and January 1970 in milliseconds. Detection is by magnitude rather than digit count, because a ten-digit number is not reliably seconds and a negative timestamp — a date before 1970 — has no useful digit count at all. Because the assumed unit is shown with the result, a wrong guess is visible rather than silent.
Timestamps that trip people up
-
The unit is the usual error:
seconds and milliseconds differ by a factor of a thousand, which turns a recent date into 1970 or a plausible date into the far future. The result states which unit was assumed.
-
Timestamps are always UTC:
the number has no timezone. Any local time you see is your device applying its own offset, so the same timestamp displays differently on two machines.
-
Negative is valid:
dates before 1970 are represented by negative numbers, and they are handled here rather than rejected.
-
Leap seconds are not represented:
Unix time skips them by definition, so it is not a true count of elapsed SI seconds. This matters for precision timing and almost nothing else.
The same ten digits can mean two entirely different moments
1700000000 is a date in November 2023 read as seconds, and a date in January 1970 read as milliseconds — identical digits, two moments more than fifty years apart. The [msm_tool slug="time-converter"] exists specifically to remove that ambiguity, detecting the unit from the number's magnitude and stating which one it assumed directly alongside the converted result.
Why magnitude beats counting digits
A ten-digit number is not reliably seconds on its own, and a negative timestamp — a date before 1970 — has no useful digit count to reason from at all. Detecting the unit from how large the number actually is, rather than simply how many digits it has, is what lets seconds, milliseconds, microseconds and nanoseconds all be handled through the same input without asking which one was intended first.
Every timestamp is UTC; what you see locally is your device's doing
The number itself carries no timezone whatsoever. Any local time shown is your own device applying its own offset at display time, which is exactly why the same timestamp can appear as two different clock times to two people looking at it from different places — comparing the raw UTC values directly is the way to be certain both people are actually discussing the same moment.
Negative numbers are a normal part of the format
A negative timestamp represents a genuine moment before 1970 and is handled correctly here rather than rejected. Where a system refuses negative timestamps, that refusal is a limitation of that particular system rather than anything wrong with the timestamp itself.
Why the year 2038 shows up in timestamp discussions
Systems that store Unix time in a signed 32-bit integer run out of range in January 2038 and wrap around to a negative number, silently jumping to a date in the past instead of the future one that was actually meant. Anything using a 64-bit timestamp is unaffected for a span of time considerably longer than the universe has existed so far.