Unix timestamp seconds vs milliseconds is one of those bugs that looks tiny but breaks dates completely. A value can point to the right moment or land thousands of years away depending on the unit. Use the Unix Timestamp Converter after you confirm whether your value is in seconds, milliseconds, or another precision.
Use the tool instead of doing this by hand
Convert Unix timestamps and debug time-zone issues faster.
This article is for developers, analysts, and support teams who see a timestamp and wonder why the converted date looks wrong even though the number came from a real system.
Table of Contents
Unix timestamp seconds vs milliseconds: the quick difference
A Unix timestamp counts time from January 1, 1970 at 00:00:00 UTC. In many systems, the count is stored in seconds. In JavaScript, dates often use milliseconds. That difference means the same moment can be represented by two numbers with very different lengths.
For example, a timestamp in seconds may have 10 digits. The same moment in milliseconds usually has 13 digits. If you treat a 13-digit millisecond value as seconds, the converted date can jump far into the future. If you treat a 10-digit second value as milliseconds, the date may appear near January 1970.
The math is simple: milliseconds are seconds multiplied by 1000. The bug happens because systems rarely label the unit clearly.
Where this timestamp bug appears
APIs are a common source. One endpoint may return seconds, while another returns milliseconds. A team may assume both fields use the same unit because the names look similar.
JavaScript is another common place. The MDN documentation for the Date object explains that JavaScript date values are based on milliseconds since the epoch: JavaScript Date reference. That means a timestamp from a backend service may need multiplying or dividing before it is used in browser code.
Logs can be even trickier. Some logs use seconds, some use milliseconds, and some use microseconds or nanoseconds. Long values are not always milliseconds, especially in high-performance systems.
Unix timestamp seconds vs milliseconds: 7 bug checks
First, count the digits. Ten digits usually suggest seconds for modern dates. Thirteen digits usually suggest milliseconds. This is not perfect, but it is a fast clue.
Second, read the API documentation. Field names like created_at, timestamp, time, and date do not guarantee the unit. Look for wording such as seconds, ms, epoch milliseconds, or Unix time.
Third, test one known date. If you know when an account was created or when an event happened, convert that timestamp and compare it with the expected date.
Fourth, check JavaScript usage. If the code passes a raw timestamp into new Date(), JavaScript expects milliseconds. A seconds value needs to be multiplied by 1000 first.
Fifth, do not confuse unit bugs with timezone bugs. A seconds-vs-milliseconds bug can move dates by decades or centuries. A timezone bug usually moves the time by hours. If the issue is timezone-related, the Time Zone Converter is the better supporting tool.
Sixth, watch for database conversions. Some databases store epoch seconds, while application code expects milliseconds. Document the contract at the boundary between storage and code.
Seventh, keep developer utilities nearby. The Developer Tools hub can help with related debugging tasks such as formatting JSON, converting values, and checking encoded data.
How to prevent this bug in real teams
The best prevention is naming. A field called timestamp_ms is harder to misuse than timestamp. A field called createdAtEpochSeconds is verbose, but it tells future developers exactly what to expect.
Tests also help. Add a test with a known timestamp and expected readable date. If someone later changes the unit or parsing logic, the test catches it before production users see impossible dates.
Finally, format dates at the edge of the system. Keep raw timestamps consistent internally, then convert them for display where timezone, locale, and user expectations are known.
Final thought
Unix timestamp seconds vs milliseconds is a small unit mismatch with a loud failure mode. Count digits, check documentation, test a known value, and be careful when moving between backend systems and JavaScript. Most timestamp bugs become obvious once the unit is confirmed.
Timestamp debugging workflow for teams
A reliable timestamp debugging workflow starts by collecting three pieces of evidence: the raw value, the expected human date, and the system that produced it. Without all three, developers often guess whether the value is seconds or milliseconds and waste time chasing the wrong cause.
Next, check the value length and convert it both ways. If one conversion lands near the expected event and the other lands near 1970 or far in the future, the unit mismatch becomes obvious. This simple comparison is often faster than reading through several layers of application code.
After that, inspect the boundary where the timestamp moves between systems. The backend may store seconds, the API may serialize milliseconds, and the frontend may expect JavaScript Date input. Bugs usually happen at these handoff points, not inside the timestamp itself.
It also helps to log timestamps with labels. A debug line that says createdAtMs=1717000000000 is far clearer than createdAt=1717000000000. Explicit names reduce future confusion and make support tickets easier to understand.
Finally, add a regression test with a known timestamp. Pick one fixed value, convert it, and assert the expected date. That small test can prevent the same Unix timestamp seconds vs milliseconds bug from returning during refactors.
Unix Timestamp Seconds vs Milliseconds FAQ
How do I know if a Unix timestamp is in seconds or milliseconds?
For modern dates, 10 digits usually suggests seconds, while 13 digits usually suggests milliseconds.
Why does JavaScript show the wrong date for my timestamp?
JavaScript Date expects milliseconds, so a Unix timestamp in seconds must usually be multiplied by 1000 first.
Can timezone settings cause the same problem?
Timezone settings usually shift times by hours, while seconds-vs-milliseconds mistakes can shift dates by decades or centuries.
Should APIs label timestamp units?
Yes. APIs should label timestamp units clearly with names or documentation so developers know whether values are seconds or milliseconds.