A countdown decrements a seconds counter inside setInterval(tick, 1000) and renders it. On a busy page it is noticeably behind real time after an hour. Why does that happen, and how would you make it accurate?

## Why the counter drifts The bug is a category error: the code uses "number of timer callbacks that have run" as a proxy for "seconds elapsed". Those two quantities are only equal if every callback runs exactly 1000 ms after the previous one, and a timer never promises that. A timer delay is a **lower bound**. When the delay expires the callback becomes *eligible* to run; it still has to wait for the currently running task to finish and for anything queued ahead of it. So every tick is late by some amount `L >= 0`. The error has a sign — ticks can never be early — so it never cancels out. It integrates. Over 3600 ticks, an average lateness of two milliseconds is seven seconds of visible error; on a page doing real work, average lateness of tens of milliseconds is ordinary, and the countdown is minutes wrong. With `setInterval` specifically, the next occurrence is armed relative to the current (already late) dispatch, so today's lateness becomes part of tomorrow's baseline rather than being corrected away. ## And then there are the gaps Accumulating milliseconds is the mild case. The severe case is time during which the timer does not fire at all: the machine sleeps, the process is suspended, the main thread is blocked for seconds by a long synchronous task. When execution resumes, the tick count has not advanced but real time has moved on by minutes. No amount of per-tick correction recovers that, because the information was never in the tick stream to begin with — it is only in the clock. ## The fix: read the clock, do not count the chimes Decide what the timer is *for*. In a countdown, the ground truth is a deadline; the timer's only job is to decide how often you re-render. ```js const deadline = Date.now() + 60_000; const id = setInterval(() => { const remaining = Math.max(0, deadline - Date.now()); render(Math.ceil(remaining / 1000)); if (remaining === 0) clearInterval(id); }, 250); ``` This is correct under every failure mode above. A late tick renders the correct smaller number. A five-second stall renders a value five seconds lower when it resumes. Waking from sleep shows the true remaining time immediately. You can even change the tick rate for smoother updates without touching correctness — which is the tell that the design is right. ## Drift-corrected scheduling, when the tick itself must be aligned Rendering from the clock fixes *what you show*. Sometimes you also need *when you fire* to stay near the intended boundary — the second digit should change close to the real second, or a sampler should keep an even average rate. That calls for a self-rescheduling `setTimeout` whose delay is computed each cycle: ```js const interval = 1000; const start = performance.now(); let count = 0; function tick() { count += 1; const expected = start + count * interval; const late = performance.now() - expected; render(count); if (count < 3600) setTimeout(tick, Math.max(0, interval - late)); } setTimeout(tick, interval); ``` The key line is `expected = start + count * interval`: the target is derived from an absolute origin, not from the previous tick, so a late tick shortens only the *next* delay and the schedule pulls itself back rather than sliding. `Math.max(0, ...)` handles the case where a tick was so late that the next target is already past. ## Date.now versus performance.now Use `Date.now()` when the ground truth is wall-clock — a deadline, a timestamp shown to a human, a value compared against a server time. Use `performance.now()` when you are measuring *elapsed* time: it is monotonic and expressed as a floating-point millisecond offset from a page or process origin, so a user changing the system clock or an NTP correction cannot make it jump or run backwards. `Date.now()` can do exactly that, and a clock adjustment mid-countdown will visibly warp a naive elapsed-time calculation. Note that `performance.now()` resolution is deliberately coarsened by browsers for security reasons, so treat it as sub-millisecond-ish rather than exact. ## What an interviewer is listening for The weak answer is "timers are inaccurate, so use a shorter interval" — which changes nothing, because shorter ticks accumulate error faster. The strong answer names the sign of the error and its accumulation, distinguishes "how often I update" from "what time it is", picks the clock that matches the ground truth, and mentions the suspend/sleep case that no per-tick correction can fix.