What is live time?
Most clocks on the web are not really clocks. They are a timestamp rendered once when the page loaded, frozen at that instant and growing quietly more wrong with every minute the tab stays open. Live time is the opposite idea: a readout that keeps advancing under its own power, so the figure on screen is the figure now.
A live time readout queries the current instant many times a second and repaints, so it never falls behind and never needs a refresh. Static timestamps are everywhere and they are usually harmless: a comment posted at 14:02 does not need to update. Problems begin when a page that was cached, printed or screenshotted is treated as current. A cached page can serve a timestamp that is hours old without looking any different from a fresh one. Live time sidesteps that entirely, because there is nothing stored to go stale.
Early web clocks were server-rendered timestamps. The server wrote the time into the HTML, and when the page loaded, that was that. Then JavaScript’s Date object arrived in 1995 with Netscape 2, and client-side live clocks became possible. The tab could ask the operating system for the time and show it, no server involved.
How does a live clock update without drifting?
A live clock stays moving using one of two mechanisms. The older approach is setInterval, which asks the runtime to execute a function after a delay. Ask for 1000 milliseconds and you get a callback roughly a second later. The problem is that setInterval promises a minimum delay, never an exact one. If the main thread is busy doing something else, the callback arrives late, and the clock falls behind. Over minutes, that drift compounds. A clock using setInterval can silently run slow.
The better approach is requestAnimationFrame, standardized in 2011. It hands the tab a callback just before each repaint, so on a 60 Hz screen it fires roughly every 16.7 milliseconds, and each frame asks what the time is now instead of assuming how much time has passed. A clock that re-reads the system time on every frame cannot accumulate error, because each frame is an independent question with a fresh answer. Higher refresh rates simply mean the question is asked more often; 120 Hz and 144 Hz screens get proportionally faster updates, which is why a live clock with milliseconds looks smoother on a gaming monitor.
requestAnimationFrame pauses entirely in hidden tabs across all major clients. The clock stops updating when you switch away, and it recalculates from system time when you return. This is what makes live time trustworthy over a long session rather than only for the first few minutes.
The role of Date.now() in a live readout
Date.now() returns the number of milliseconds elapsed since 1 January 1970 00:00:00 UTC, the Unix epoch. That single number is the raw material of every live clock. The tab formats it into hours, minutes, seconds and milliseconds, but underneath it is just an integer that grows by roughly 1000 every second.
Date.now() calls the operating system’s clock. There is no independent time source inside the runtime. No API exposes NTP status, stratum level, or last sync time to JavaScript. The tab cannot know whether your system clock is accurate to a millisecond or off by an hour; it simply reports what the OS gives it.
The second itself is defined by atomic clocks. National laboratories run those clocks and feed the result into the Network Time Protocol (NTP), which distributes it across the internet. Your computer contacts an NTP server periodically and nudges its own clock into line. Between check-ins, timekeeping falls to a quartz crystal oscillator on the motherboard, and quartz is good rather than perfect: typical drift runs 1 to 15 seconds per month for consumer hardware.
That chain is the accuracy live time inherits. The tab is exactly as accurate as the machine it runs on, and not one millisecond more.
Why a live clock never contacts a server
Because the time comes from the operating system, there is no round-trip to a server. No network request means no latency, no dependency on a connection, and no privacy leak. The website never learns what time you see; it cannot use your clock to fingerprint you or track your location. Live time works offline for the same reason a calculator works offline: the computation happens entirely on your device.
This is a meaningful difference from the early web, where every timestamp was baked into the HTML by a server. A live clock built with JavaScript makes no request after the initial page load, so it costs nothing to run and reveals nothing about you.
Does live time work without an internet connection?
A live clock keeps ticking with the network cable pulled. The system reads the system time, formats it, and paints it to the screen. None of those steps involve a connection. This is why a live clock works in an airplane, in a conference room with the Wi-Fi down, or on a machine that has never seen the internet.
The clock is only as correct as the system clock behind it. A device that has not synced in months will show the wrong time with perfect confidence. The runtime cannot tell the difference between an accurate system clock and a wrong one. It reports what the OS says, and the OS believes what its quartz crystal tells it.
Live time vs static timestamps
A static timestamp is a snapshot. It records a moment and then goes stale. A live readout is a continuous display. The difference matters whenever the shown value is supposed to be “now” rather than “whenever this page happened to load.”
Static timestamps have their place. A comment posted at 14:02 should not keep updating. An article published at 09:15 on Tuesday should not show Wednesday’s date. But the moment a timestamp is treated as current after time has passed, it becomes misleading. Live time eliminates that category of error entirely, because there is nothing stored to go stale.
Privacy: what websites can and cannot see
A live clock reveals nothing about you. It does not transmit your time zone, your system clock offset, or even the fact that you looked at a clock. The tab reads the time locally and shows it locally; the website operator never sees the value.
What websites cannot see is worth making explicit: they cannot see your NTP sync status, your last sync time, or whether your clock is accurate. No API exposes that information to a script. The only way a website could learn about your clock would be if you told it, or if it ran a script that measured network latency and compared it against a server timestamp, a technique that reveals round-trip time, not your system time.
Where live time readouts get used
Live time readouts show up wherever the current instant matters more than a stored value. Streaming overlays use them so viewers see the streamer’s local time ticking in real time. Operating rooms and treatment areas use wall-mounted screens with large digits, accurate to the second, always visible. Lobby and kiosk screens run unattended for weeks, surviving power cycles and auto-recovering without interaction.
Factory floors use them because a visible clock keeps production schedules honest. Deposition and interrogation rooms use them because an unambiguous, continuously updating readout serves everyone in the room. Gym displays, exam timers, and presentation clocks all rely on the same mechanism: a display that re-reads the system time on every animation frame.
The Pomodoro Technique, 25 minutes of work followed by 5 minutes of break, depends on a timer that keeps running in the background. A live countdown timer is the same idea as a live clock, just counting down instead of up.