Why a Valid Timestamp Can Show January 1970
Unix time counts elapsed seconds from 1970-01-01T00:00:00Z. JavaScript’s Date constructor, however, expects milliseconds. Passing a 10-digit seconds value directly to new Date() makes JavaScript interpret it as a much smaller millisecond value near the beginning of 1970.
The reverse mistake—multiplying a value that is already milliseconds by 1000—creates a date far into the future. The number itself may be valid; the unit is wrong.
Use Digit Count as a Fast First Check
Around the current era, seconds are generally 10 digits and milliseconds are generally 13 digits. This is a quick diagnostic, not a permanent rule: timestamps before 2001, future timestamps, and microsecond or nanosecond values need more careful handling.
When documentation is unclear, inspect a known sample. If the API says a recent event happened today but its numeric value looks like 1710000000, it is almost certainly seconds.
Store timestamps in UTC. Convert to a visitor’s timezone only when presenting a date or time to a person.
Safe JavaScript Conversion
For seconds, use new Date(seconds * 1000). For milliseconds, use new Date(milliseconds).toISOString(). Keep the unit in the variable name—createdAtSeconds is much safer than createdAt.
For values outside JavaScript’s safe integer range, use a system that preserves integer precision. Precision loss can silently change a timestamp or identifier before any date conversion happens.