Unix Timestamp Converter

How it works

The date picker produces a JavaScript Date, which represents a number of milliseconds since the epoch. Seconds mode divides that number by 1,000 and floors it because Unix timestamps in seconds do not carry fractional milliseconds. Milliseconds mode keeps the original integer. The reverse operation multiplies seconds by 1,000, constructs a Date, and formats it with toISOString, making the UTC timezone explicit rather than inheriting the reader's locale.

The converter does not parse ambiguous natural-language phrases such as “next Friday” or silently assume a timezone for a date-only string. The visible date picker supplies a timezone-aware local instant. Numeric input is checked for finiteness and for a valid JavaScript date range before it is displayed, so a typo becomes a visible error rather than an apparently plausible year.

When developers use it

Timestamp conversion is useful while debugging event logs, checking expiry claims, preparing seed data, comparing browser and API output, and translating a database value into a date a human can discuss. It is also a quick way to spot a unit mismatch: a timestamp that lands thousands of years away is usually a seconds-versus-milliseconds mistake.

The result is an interpretation, not a validation of business logic. A timestamp can be perfectly formatted and still be expired, in the wrong field, or generated by a machine with a bad clock. Use the UTC line as documentation and let the receiving application decide whether the value is acceptable.

Telling seconds from milliseconds at a glance

The unit mismatch is the most common timestamp bug and the easiest to spot once you know what the numbers look like.

A current timestamp in seconds is ten digits and starts with 17. The same instant in milliseconds is thirteen digits. That is the whole test: count the digits. Ten means seconds, thirteen means milliseconds, and anything else deserves suspicion.

The two classic wrong answers are recognizable too. Feed a seconds value to something expecting milliseconds and you land in January 1970, because you have described a moment about twenty days after the epoch. Feed a milliseconds value to something expecting seconds and you get a date somewhere around the year 56,000. Both are so far from plausible that they are easy to catch — which is the good case.

The dangerous case is a timestamp in a unit that is merely wrong rather than absurd: microseconds (sixteen digits) and nanoseconds (nineteen) both appear in tracing and database systems, and dividing one by a thousand too few times gives a date that looks like a real date. If a value comes from an unfamiliar system, convert it before assuming, and check that the result is near today.

Unix time also has no concept of leap seconds — the same value is repeated across one, so a Unix timestamp is not a count of elapsed seconds since 1970. It does not matter for scheduling and does matter for precise interval arithmetic.

The 2038 problem is still real in some places

A signed 32-bit integer runs out on 19 January 2038, at which point it wraps to December 1901.

This is not a concern for JavaScript, which stores timestamps as a double, or for any modern 64-bit system. It is a live concern in three specific places: embedded devices and firmware that will still be running in a decade, database columns explicitly typed as a 32-bit integer, and file formats or protocols with a fixed four-byte time field.

It is worth checking now rather than then, because the failure arrives early. Anything that computes an expiry date, a retention period, or a maturity date more than a decade ahead is already producing 2038-range values today. A subscription system that offers a twenty-year term is doing this arithmetic in the present, and a wrapped date usually surfaces as a record that looks expired rather than as an obvious crash.

If you own a schema, check the column type on anything storing a time as an integer. Sixty-four bits costs four extra bytes and removes the question entirely.