Short answer
- A 10-digit Unix timestamp is usually seconds.
- A 13-digit Unix timestamp is usually milliseconds.
- If the converted date lands decades away from the expected period, the timestamp unit is probably wrong.
Quick unit check
| Example | Likely unit | Why |
|---|---|---|
| 1717200000 | Seconds | 10 digits, common API and database epoch format |
| 1717200000000 | Milliseconds | 13 digits, common JavaScript Date timestamp format |
| 1717200000000000 | Microseconds | 16 digits, often from databases or event systems |
| 1717200000000000000 | Nanoseconds | 19 digits, often from high-resolution logs |
UTC vs local time
Unix time is anchored to UTC. Displaying that moment in a local timezone can change the visible hour and sometimes the visible date.
When debugging logs or API payloads, compare the UTC output first, then use local time only when the user-facing timezone matters.
Timestamps in JSON payloads
APIs may send timestamps as numbers, numeric strings, ISO date strings, or nested fields with unit names. Format the payload before deciding what a field means.
If you generate TypeScript from example JSON, review timestamp fields manually. A generator can infer number or string, but it cannot know whether the number is seconds or milliseconds.
Common mistakes
- Passing seconds into JavaScript Date without multiplying by 1000.
- Treating a millisecond timestamp as seconds and landing far in the future.
- Comparing local-time displays when the source system stores UTC.
FAQ
Why does my timestamp convert to a date in 1970?
You may be treating seconds as milliseconds. A small seconds value passed into a millisecond-based converter can display near 1970.
Why does my timestamp convert to a date far in the future?
You may be treating milliseconds as seconds. A 13-digit millisecond value interpreted as seconds becomes much too large.
Are Unix timestamps timezone-specific?
No. Unix timestamps represent a moment in UTC. Timezones only affect how that moment is displayed.