Countdown to Date

Why a naive timer runs slow

setInterval does not fire on a fixed schedule. It waits the requested delay after the previous callback returns, so any lateness — timer resolution, a busy page, a slow callback — is carried into every subsequent tick rather than corrected. Measured against a perfect schedule:

The lateness per tick is roughly constant, so the total error grows with the number of ticks rather than with elapsed time — which means a faster timer drifts further, not less. The hourly column is arithmetic on a few seconds of measurement rather than an hour-long run, but the per-tick figure it rests on is measured.

The fix is to stop asking “how long until the next one”

Keep the start time. Before each tick, work out when tick n+1 is supposed to happen and wait exactly that long from now. A late tick then shortens the next delay instead of pushing it:

const target = start + (n + 1) * period;
setTimeout(tick, Math.max(0, target - performance.now()));

Measured the same way, accumulated error over 200 ticks falls from 80.2 ms to under 0.4 ms. The individual ticks are no more punctual — they still land late by whatever the event loop costs — but the error stops compounding, which is the part that matters for a clock.

The same reasoning applies to the countdown itself: show the remaining time by subtracting now from a fixed end timestamp, rather than by taking a second off a running total each tick. Then the display is right even if the tab was backgrounded, the timer was throttled, or the machine went to sleep — because it never depended on the ticks arriving at all.