Seconds vs milliseconds in Unix timestamps.
This page exists because the most common timestamp bug is not a timezone bug. It is a unit bug. Developers and analysts routinely confuse 10-digit epoch seconds with 13-digit epoch milliseconds.
Unix Timestamp
Use the live Unix timestamp, convert timestamps, understand seconds vs milliseconds, and learn the important system boundaries.
At a glance
Use the number of digits first, then confirm the source system.
| Unit | Example | What it means |
|---|---|---|
| Seconds | 1717929600 | 2024-06-09 00:00:00 UTC |
| Milliseconds | 1717929600000 | 2024-06-09 00:00:00 UTC |
| Microseconds | 1717929600000000 | Often used in analytics pipelines and databases |
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.
Related Tools
Continue with adjacent calculators and references that solve the next step.
Avoid the factor-of-1,000 bug
Keep the unit in the field name
Use names such as created_at_seconds or created_at_ms instead of a bare time field when an interface permits it. Record the unit in a schema or data dictionary. A value’s digit count is a clue, but metadata is more reliable.
To convert seconds to milliseconds, multiply by 1,000. To convert milliseconds to whole epoch seconds, divide by 1,000 and choose a documented rounding rule. Floor is used by this site’s current-second counter.
Precision and negative values
Converting to whole seconds discards fractional information. Converting back cannot recover it. Before truncating imported data, decide whether subsecond ordering matters.
For negative values, floor and truncation differ. An instant 500 milliseconds before the epoch has a value of −0.5 seconds; flooring gives −1, while truncation toward zero gives 0. Choose the operation required by your storage format.
1768435200 seconds × 1,000 = 1768435200000 milliseconds. Both represent January 15, 2026 at midnight UTC. Keep the unit with either representation.
A common mistake to avoid
Multiplying a value that is already in milliseconds by 1,000 sends the converted date far into the future.