Unix timestamps: seconds or milliseconds?
A timestamp is a number only after you know its unit and epoch. Treating seconds as milliseconds—or the reverse—can move a date by decades or thousands of years.
What Unix time represents
Unix time commonly counts seconds from the Unix epoch, 1970-01-01 00:00:00 UTC. Many APIs and logs use a signed integer in seconds, while browser JavaScript uses milliseconds for its built-in Date time value. Other systems may use microseconds, nanoseconds, or an entirely different epoch, so check the source format before converting.
A quick magnitude check
For dates in the 2000s, a seconds timestamp is commonly around ten digits and a milliseconds timestamp around thirteen. This is a useful clue, not a reliable format specification: values can be rounded, negative, truncated, or use another unit. Prefer explicit metadata or documentation when available.
Seconds: 1,700,000,000
Milliseconds: 1,700,000,000,000The two values above refer to the same approximate instant. The millisecond value is the seconds value multiplied by 1,000.
Convert deliberately in JavaScript
const seconds = 1_700_000_000;
const date = new Date(seconds * 1000);
console.log(date.toISOString());Date expects milliseconds. Passing 1_700_000_000 directly makes JavaScript interpret it as milliseconds after 1970, not seconds. Conversely, dividing a millisecond value by 1,000 is needed when an API expects Unix seconds.
An instant is not the same as its display
A Unix timestamp identifies an instant. A formatted clock time also needs a time zone. The same instant can be shown as different local dates and times in Zagreb, London or New York. When comparing logs, convert to UTC first or make the display zone explicit; do not assume two different clock readings represent different instants.
JavaScript's ISO string method, toISOString(), formats a date in UTC. Methods such as toLocaleString() normally use the environment's locale and time zone unless options specify otherwise. Daylight-saving rules affect local display, not the underlying timestamp number.
What about the year 2038?
The well-known 2038 issue concerns systems that store Unix seconds in a signed 32-bit integer: that representation reaches its maximum in January 2038. It does not mean every timestamp, database or modern system will fail then. The actual risk depends on the integer width and how each component handles dates.