Unix Timestamps: How to Tell Seconds From Milliseconds

Unix timestamps are simple numbers that represent elapsed time from the Unix epoch, 1970-01-01 00:00:00 UTC. The trouble is that different systems use different units. Seconds and milliseconds are both common, and a value in the wrong unit can produce a date decades away from the intended event. When logs, APIs, and browser code disagree about time, start by identifying the unit before changing time zones. ## Recognize the size of the number In 2026, a Unix timestamp in seconds is around ten digits. A timestamp in milliseconds is around thirteen digits. This is a useful clue, not a complete rule. Historical dates, future dates, microseconds, and custom systems can use other ranges. Treat the magnitude as a hypothesis and verify it against a known date. For example, dividing a thirteen-digit value by 1,000 before constructing a JavaScript `Date` usually turns an accidental millisecond timestamp into seconds. Passing seconds directly to `new Date()` produces a date close to 1970 because JavaScript expects milliseconds. The same distinction appears in database drivers, logging libraries, and API documentation. ## Keep UTC and local time separate A timestamp identifies an instant, while a formatted date includes a time zone and display convention. Convert the instant first, then choose the time zone for presentation. Do not “fix” a timestamp by adding or subtracting hours until the display looks right. That approach breaks across daylight-saving changes and makes the stored value harder to reason about. When comparing logs, record the source system, unit, and time zone shown by the logger. A server may store UTC while a browser displays local time. Two lines with different-looking clock values can describe the same instant. Conversely, two identical clock values from different time zones may represent different moments. ## Validate with a known event Use an event whose time you can confirm, such as the creation time of a test record or a request captured in both browser and server logs. Convert the value as seconds and as milliseconds, then see which result is plausible. Check that the result is inside the expected operational window. A conversion that produces a plausible date is still wrong if it shifts the event by a fixed offset. For APIs, document the unit in the field name or schema when possible. Names such as `created_at` require a separate contract; `created_at_unix_seconds` makes the assumption visible. ISO 8601 strings are often easier for humans to inspect, but they still need a defined time zone or offset. Choose one representation and apply it consistently across boundaries. The CalcSnippets Timestamp Converter is useful for a quick seconds-versus-milliseconds check and for comparing a date with its numeric representation. Use it as an inspection aid, then confirm the unit in the producer's documentation and tests. Once the unit is explicit, most timestamp bugs stop being mysterious. When you store converted values, keep the original input and the interpretation that produced the normalized value during an investigation. This makes it possible to reproduce a report later and prevents a second conversion from being applied accidentally. A short note in the API contract is often enough: state the unit, state that the value is UTC-based, and include one example that a client can test.