Timestamp Converter

A Unix timestamp is simply the number of seconds that have elapsed since midnight UTC on 1 January 1970 — an arbitrary reference point chosen decades ago that has since become the near-universal default for representing a point in time inside a computer system. The appeal is that it reduces a date and time to a single, easily comparable, easily stored integer: checking whether one moment is before another is a simple numeric comparison rather than a calendar calculation, and storing it takes a fixed, predictable amount of space regardless of which century the date falls in. This is why it underlies everything from database timestamp columns to API responses to log file entries, even though the raw number is meaningless to a person looking at it directly — which is the entire reason a converter like this one exists.

A Unix timestamp representing the current moment in seconds is ten digits long, and the same instant expressed in milliseconds is thirteen digits — three additional digits for the thousandths precision. This length difference is the fast, reliable way to identify which unit a given number is in, and it also explains the two most common and most confusing failure modes when the wrong assumption is made. Passing a millisecond value to code expecting seconds multiplies the apparent date by roughly a thousand, landing somewhere in the year 55000 — spectacularly, obviously wrong. Passing a seconds value to code expecting milliseconds does the opposite: dividing the real elapsed time by roughly a thousand, which lands the interpreted date somewhere in 1970, close enough to a plausible-looking date that it is sometimes mistaken for a genuine bug elsewhere rather than a units mismatch.

A raw Unix timestamp carries no timezone information at all — it is simply a count of elapsed seconds, identical everywhere on Earth at any given instant — and the moment of converting it to a human-readable date is where a timezone has to be chosen for display purposes. Storing and logging events using UTC (or the raw timestamp itself, which is timezone-independent by definition) means every record in a system means exactly the same instant regardless of which timezone the server, the database, or the person reading the log happens to be in. Converting to local time is a display-layer decision made only when a human is actually looking at the value, which is why this tool separates the two clearly: UTC and ISO 8601 as the values worth storing and comparing, local time as the version worth reading.

A meaningful amount of older infrastructure — legacy C code, some embedded systems, certain older database column types — stores a Unix timestamp in a signed 32-bit integer, which has a hard ceiling: it overflows at 03:14:07 UTC on 19 January 2038 and wraps around to a date in 1901, a bug with the same underlying shape as the Y2K problem but rooted in binary integer limits rather than two-digit years. JavaScript represents numbers as 64-bit floating point values, which have vastly more headroom and are not subject to this specific overflow, so a timestamp calculated in this tool is unaffected — the concern applies to whatever system originally produced the timestamp being converted, not to the conversion happening here.