Countdown Timer — Days to Date, New Year & Christmas Countdown

Chromium tab throttling (Chrome 87 stable, 17 November 2020) caps background `setInterval` and `setTimeout` callbacks to a 1 Hz minimum to save battery on laptops and mobile; Chrome 88 (January 2021) intensive throttling further reduces wake-ups to once per minute for tabs hidden > 5 minutes. A countdown that increments a counter via `setInterval(fn, 1000)` will drift behind real time when its tab is backgrounded — the counter says "5 hours left" when wall-clock says 4 hours left. The recompute pattern — `target − Date.now()` on every tick — bypasses the drift entirely: each visible tick reads the current time fresh, so the displayed countdown reflects actual remaining time regardless of how often the tick runs. Trade-off: when the tab is backgrounded, the countdown freezes visually until refocus, then jumps to the correct value. Combined with the W3C Page Visibility API (Recommendation 2013), the page can re-render immediately on the visibilitychange event when the tab returns to foreground.

The Y2038 problem is the Unix timestamp wraparound: POSIX time_t (per IEEE Std 1003.1) is traditionally a signed 32-bit integer counting seconds since the Unix epoch 1970-01-01T00:00:00Z. The maximum signed 32-bit integer 2³¹ − 1 = 2,147,483,647 corresponds to 03:14:07 UTC on Tuesday 19 January 2038 — past that moment, the counter overflows to negative values, breaking date arithmetic and making any countdown to a date past 2038 silently wrong. Modern systems have moved to 64-bit time_t: Linux kernel 5.6 (March 2020), macOS 10.7 Lion (2011), Windows NT internally for decades. Embedded systems (industrial control, cars, household appliances), legacy databases, and 32-bit binaries on 64-bit operating systems remain vulnerable. JavaScript's Date object uses IEEE-754 double-precision ms-since-epoch (range ±100,000,000 days from 1970), so browser countdowns are unaffected through the year 275760 — but if the countdown target is processed by a server, file format, or device with 32-bit time_t, the wraparound becomes visible.

A countdown using local wall-clock time can show ±1 hour visible discontinuity at a DST boundary. EU spring-forward (last Sunday of March, +1 hour: clocks jump 02:00 → 03:00 in CET, equivalently 01:00 UTC per Directive 2000/84/EC) makes a countdown that targets a date past the boundary lose 1 hour at that moment — the visible "5 hours 30 minutes" becomes "4 hours 30 minutes". EU fall-back (last Sunday of October, −1 hour: clocks repeat 03:00 → 02:00 in CET) does the inverse — the countdown gains 1 hour. US DST runs on different Sundays (second Sunday of March, first Sunday of November) per the Energy Policy Act 2005. A countdown using UTC sidesteps this entirely (UTC has no DST) but loses local human framing — "3 hours until midnight" reads naturally only in local time. The page treats the target as wall-clock local time, so DST-boundary discontinuities are visible by design.

Browser clocks rely on the operating system clock, which is synchronised to internet time via NTP (Network Time Protocol, RFC 5905, typical drift on the order of a few tens of milliseconds when network-connected). The countdown's accuracy is therefore bounded by the OS clock accuracy plus the JavaScript event-loop tick granularity (usually 4-16 ms via requestAnimationFrame, or 1000 ms throttled in background tabs per the Chromium policy above). For practical countdowns (deadlines, holidays, events), this is more than accurate enough — a few milliseconds of drift per minute is invisible. For sub-second precision (e.g., New Year's Eve countdown to a specific server clock), the page would need to fetch server time periodically and adjust — which most countdown UIs don't bother with because OS NTP keeps clocks within a few hundred milliseconds of real time globally.

The W3C Page Visibility API (Recommendation 29 October 2013) exposes whether a tab is currently visible to the user via `document.hidden` (boolean) and the `visibilitychange` event. It's the standard mechanism browsers use to inform pages about tab focus state, separate from the older `window.focus`/`blur` events (which fire only for tab+window focus, not tab-switch within a window). Combined with the Date.now() recompute pattern, a countdown can: (a) skip animation frames while hidden to save CPU, (b) jump directly to the correct value when the tab returns to foreground (via the visibilitychange event firing with `document.hidden = false`). Modern browsers throttle setInterval to 1 Hz minimum in hidden tabs (Chromium tab throttling, Chrome 87 stable 17 November 2020) regardless, so the Page Visibility API mainly helps with re-sync on refocus rather than reducing throttling.