Debugging Common Timestamp Bugs

Timestamp bugs are among the most frustrating to debug — they often only appear in production, in specific timezones, or at daylight saving time transitions. Here are the most common ones and how to fix them.

Bug 1: Seconds vs Milliseconds confusion

This is the most common timestamp bug. JavaScript's Date.now() returns milliseconds, but most other languages return seconds. Mixing them up gives dates in 1970 or the year 55000.

// ❌ Wrong: treating ms as seconds
const date = new Date(1700000000); // 1970-01-20 (wrong!)

// ✅ Correct: ms needs no conversion
const date = new Date(1700000000000); // 2023-11-14 (correct)

// ✅ Converting seconds to ms
const date = new Date(1700000000 * 1000); // 2023-11-14 (correct)

Quick check: a 10-digit number is seconds, a 13-digit number is milliseconds. Use our converter tool to verify.

Bug 2: Off-by-one-hour timezone errors

Displaying a UTC timestamp in local time without telling the user is UTC causes hours to appear wrong. Always be explicit about the timezone when displaying times.

// ❌ Wrong: local time displayed as UTC label
const d = new Date(1700000000000);
label.text = d.getHours() + ":00 UTC"; // shows local hour with "UTC" label

// ✅ Correct: use UTC methods for UTC output
label.text = d.getUTCHours() + ":00 UTC";

// ✅ Or use toISOString which is always UTC
label.text = d.toISOString();

Bug 3: DST (Daylight Saving Time) edge cases

Clocks jump forward or back by one hour during DST transitions. If you're calculating "start of day" by adding 86400 seconds, you may land in the wrong day on DST changeover days.

// ❌ Wrong: adding 86400 seconds assumes all days are equal
const tomorrow = today + 86400; // breaks on DST day (23h or 25h day)

// ✅ Correct: use a date library to add calendar days
// JavaScript with date-fns
import { addDays } from 'date-fns';
const tomorrow = addDays(new Date(), 1);