Timestamp Converter

Why Timestamps Are Harder Than You Think

Unix timestamps count seconds from January 1, 1970 00:00:00 UTC and fit comfortably in a signed 32-bit integer up to the value 2,147,483,647 — which corresponds to January 19, 2038 at 03:14:07 UTC. On that date, any system still using 32-bit signed integers for timestamps will overflow to a large negative number, interpreting the time as December 13, 1901. This is the Y2K38 problem, and while most modern systems have migrated to 64-bit integers, embedded systems, legacy databases, and some C libraries are still at risk.

Leap seconds add another complication. The Earth's rotation is slightly irregular, so the International Earth Rotation Service occasionally inserts a leap second — 23:59:60 on the last day of June or December. POSIX time deliberately ignores leap seconds, smearing them across neighboring seconds, which means two timestamps that differ by exactly 86,400 seconds do not necessarily represent exactly one calendar day apart. GPS time, TAI, and UTC all handle this differently, which matters in high-precision logging, financial trading systems, and satellite navigation.

The most common day-to-day mistake is mixing seconds and milliseconds. JavaScript's `Date.now()` returns milliseconds; Python's `time.time()` returns seconds as a float; MySQL's `UNIX_TIMESTAMP()` returns seconds. Storing a JavaScript timestamp in a database column that expects seconds without dividing by 1,000 results in a date 1,000 years in the future — a bug that typically only surfaces in production.

Working with Timestamps in Code

Python's time.time() returns a float with sub-second precision (e.g. 1712345678.901234), while JavaScript's Date.now() returns an integer milliseconds value. When exchanging timestamps between the two, multiply/divide by 1000 and decide upfront which precision your API contract requires.

// JavaScript — milliseconds since epoch
const nowMs = Date.now();               // e.g. 1712345678901
const nowSec = Math.floor(nowMs / 1000); // convert to seconds for most APIs

// Parse a timestamp back to a Date object
const date = new Date(nowMs);           // or new Date(nowSec * 1000)
console.log(date.toISOString());        // "2024-04-05T14:21:18.901Z"
console.log(date.toLocaleString());     // local timezone string

// Compare timestamps safely
const diff = Date.now() - pastTimestampMs; // always positive if past
const secondsAgo = Math.floor(diff / 1000);

// Build a timestamp from a specific UTC date
const specific = new Date("2024-01-01T00:00:00Z").getTime(); // ms
const specificSec = specific / 1000; // 1704067200

Timestamp Pitfalls to Avoid

• Storing local time instead of UTC: local timestamps become ambiguous when servers change timezone or when users in different regions share data. Always store UTC and convert on display.
• Mixing seconds and milliseconds: a 10-digit number is seconds-based; a 13-digit number is milliseconds-based. Passing one where the other is expected shifts dates by ~31 years or collapses them to the early 1970s.
• Not handling DST transitions: on spring-forward days, one local hour does not exist; on fall-back days, one hour repeats. Date arithmetic that assumes 24 hours = 86,400 seconds breaks around these transitions.
• Assuming `Date` parsing is portable: `new Date('2024-4-5')` is treated differently across browsers and Node versions. Always use ISO 8601 format (`2024-04-05T00:00:00Z`) for unambiguous parsing.
• Ignoring Y2K38 for 32-bit systems: any embedded system, legacy database column, or C library using `int32_t` for time_t will overflow in January 2038. Audit these before deploying long-lived systems.
• Logging timestamps without timezone offset: a log line reading `14:21:18` is useless when your team spans multiple timezones. Always log in UTC or include the UTC offset in the timestamp.