Seconds vs milliseconds in Unix timestamps.

Why the confusion happens

Unix time was originally defined in seconds. Many modern platforms, especially browser JavaScript, use milliseconds instead because they need sub-second precision and because the underlying APIs expose time that way. The values represent the same instant, but the unit is different by a factor of 1,000.

This becomes dangerous when data moves between systems. A frontend may send milliseconds, while a backend expects seconds. A logging pipeline may store microseconds, while a dashboard assumes milliseconds. The result is an obviously wrong date: either somewhere in January 1970 or tens of thousands of years in the future.

How to tell which unit you have

The fastest check is the size of the number. As of the 2020s, Unix timestamps in seconds are 10 digits. Milliseconds are 13 digits. Microseconds are 16 digits. Nanoseconds are 19 digits. That heuristic is not perfect for historical dates close to 1970, but it catches most production mistakes immediately.

The second check is the system producing the value. JavaScript’s Date.now() returns milliseconds. Many REST APIs and databases return seconds. Some analytics and observability systems expose microseconds or nanoseconds for sorting high-frequency events. The source system is often a better clue than the number alone.

Safe conversion rules

To convert milliseconds to seconds, divide by 1,000 and keep the integer part if you only need second precision. To convert seconds to milliseconds, multiply by 1,000. Do not guess silently in production code. Validate the input range and store the unit in the field name or schema whenever possible.

A practical naming standard is to use explicit fields such as created_at_unix, created_at_ms, or created_at_ns. When a dataset contains multiple timestamp units, hidden ambiguity becomes an operational risk.