Epoch Milliseconds vs Seconds: Why 10 vs 13 Digits Breaks Your Timestamps

The Anatomy of the 1970 Bug

Unix time is defined by POSIX standards as the number of elapsed seconds since the **Unix Epoch**: midnight UTC on **January 1, 1970** (`1970-01-01T00:00:00Z`), excluding leap seconds.

Most backend languages (C, Python, PHP, Ruby, Go) return timestamps in seconds: ```python import time print(int(time.time())) # e.g. 1729486800 (10 digits) ```

JavaScript, however, was designed to align with Java: `Date.now()` and `new Date(value)` expect the value in **milliseconds** (13 digits): ```javascript console.log(Date.now()); // e.g. 1729486800000 (13 digits) ```

When a developer unknowingly passes a backend 10-digit timestamp directly to `new Date()`: ```javascript const created = new Date(1729486800); console.log(created.toISOString()); // Outputs: 1970-01-21T00:24:46.800Z! ``` Because 1.7 billion milliseconds is only ~20 days, the date resolves to January 1970.

Defensive Parsing in Frontend Code To build resilient timestamp parsers that automatically normalize 10-digit and 13-digit inputs:

function parseEpochSafely(timestamp) {
  const num = Number(timestamp);
  if (isNaN(num)) return null;
  // If the number is under 100 billion, it's in seconds
  const ms = num < 100000000000 ? num * 1000 : num;
  return new Date(ms);
}

Use Mickytool's **Epoch / Unix Timestamp Converter** to paste any 10-digit or 13-digit number and instantly convert it across time zones and formats.