Countdown Timers Should Target a Timestamp, Not Count Seconds

A countdown that decrements a "seconds remaining" variable every tick has the same drift problem as a stopwatch built the same way, except in reverse — and it's worse in practice, because browsers deliberately throttle setInterval in background or minimized tabs to save battery, so a timer switched away from mid-countdown can fall minutes behind by the time you switch back. The Fullscreen Countdown Timer sidesteps this by never counting down at all.

Target time, not remaining time

Pressing start computes one fixed end timestamp — Date.now() + duration — and every subsequent tick just subtracts the current time from that target. Whether the tab was throttled and the tick fired late doesn't change the target, so the displayed remaining time snaps back to correct the instant a delayed tick finally runs. Pausing works by converting the remaining time back into a stored duration, then computing a fresh end timestamp on resume — the same reset-the-reference-point trick a drift-free stopwatch uses going the other direction.

Keeping the screen on with Wake Lock

Presentations and timed talks fail in an obvious way when the display dims mid-countdown. The tool requests the Screen Wake Lock API when you start the timer and releases it on pause, reset, or completion — best-effort, since not every browser supports it, but it costs nothing to try and helps on the ones that do.

Fullscreen and multi-section pacing

The fullscreen toggle just wraps the standard requestFullscreen/exitFullscreen pair so the countdown is legible from across a room. For counting up instead of down — timing how long something actually took — the Precision Stopwatch uses the same timestamp-based approach; for pacing several timed sections back to back, like an exam, the Exam & Section Timer chains multiple countdowns automatically.