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 display that keeps advancing under its own power, so the figure on screen is the figure now. The distinction stops being academic the moment you point a camera at the screen, project it into a lobby, or use it to start a race.
This article covers what live means for a clock, where the number on your screen actually comes from, how a browser keeps it moving, and why a web page can be exactly as accurate as the machine it runs on and not one millisecond more. If you would rather watch than read, the live clock ticks continuously with milliseconds on show.
What Does Live Time Mean?
Live time means the value on screen is recalculated continuously from the device's own clock rather than printed once and left alone. A live time display reads 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. The page holds only the instructions for asking the clock again, and it asks again constantly.
Where Does The Time Come From?
The time comes from your device, not from the website. The browser asks the operating system for the current instant with Date.now(), which returns the number of milliseconds elapsed since 1 January 1970 UTC, and the page merely formats that number for human eyes.
Behind the operating system sits a longer chain. The second itself is defined by atomic clocks, which count a fixed number of transitions in the caesium-133 atom, 9,192,631,770 of them per second. 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: tens of parts per million of error is normal, which works out at a few seconds of clock drift a day and a minute or two a month if nothing corrects it. That chain is the accuracy live time inherits, and it is set out step by step in NTP vs browser time.
How The Display Keeps Ticking
A live clock repaints in step with the screen rather than on a fixed timer. requestAnimationFrame hands the page a callback just before each repaint, so on a 60 Hz display it fires roughly every 16.7 milliseconds, and each frame asks what the time is now instead of assuming how much time has passed.
That last point is the whole trick. A clock that counts its own ticks accumulates every small error it ever makes. A clock that re-reads the system time on every frame cannot accumulate anything, because each frame is an independent question with a fresh answer. Higher refresh rates simply mean the question is asked more often; a 120 Hz panel gets the same result, twice as smoothly. This is what makes live time trustworthy over a long session rather than only for the first few minutes.
Why Not Just Use setInterval?
setInterval promises a minimum delay, never an exact one. Ask for 1000 milliseconds and you will get 1000 or more, depending on what else the main thread is busy with, so setInterval drift is the norm rather than the exception. Leave one running for an hour and the seconds visibly slide, then pause and skip a number to catch up. Animation frames avoid the problem because the browser schedules them against the display refresh rate, and because a frame-based clock derives the time instead of counting it.
What Live Time Cannot Guarantee
A live time display can never be more accurate than the system clock behind it. If your device is two minutes fast, the page will confidently show a wrong time to the millisecond, because Date.now() reports what the operating system believes rather than what is true.
The system clock can also jump. An NTP correction, a manual change or a virtual machine resuming from suspend can move it forwards or backwards without warning, which is why measuring an interval with wall-clock time is a poor idea. That job belongs to monotonic clocks: performance.now() only ever moves forward and is immune to those jumps, but it measures elapsed time since the page opened rather than the time of day. Background tabs add a second limit, since browsers throttle timers heavily when a tab is hidden and stop delivering animation frames to it altogether. Both constraints are unpicked in browser clock accuracy and in millisecond precision in the browser.
Where A Live Time Display Earns Its Keep
Any situation where several people need to agree on the moment is a candidate for live time on a shared screen.
- Streaming overlays: OBS Studio can load a web page as a browser source, so the clock sits over the video on a transparent background with no extra software involved.
- Digital signage and lobby displays: a screen in reception showing the current time is the simplest signage there is, and it keeps working through a network outage because the time is read locally.
- Exam invigilation: one visible clock at the front of a hall settles every argument about whose watch was right.
- Interval training: a live countdown timer or a stopwatch with laps gives a whole room the same cue at the same instant.
- Studios and control rooms: a precision seconds counter makes the roll-over readable from across the room, which matters when a cue lands on a named second.
Getting A Live Clock Onto The Right Screen
Once the clock is correct, the remaining work is presentation. A fullscreen display mode strips away tabs and toolbars so nothing competes with the digits, and it can hold a screen wake lock so the panel does not dim halfway through a session. On a spare monitor or a signage screen, light digits on a dark background are usually kinder on the eyes and on the panel, since a static bright block is what leads to OLED burn-in. Hiding milliseconds removes a churning patch of pixels most viewers do not need. Decide what the audience is reading for: a room glancing up wants hours and minutes at a size legible from the back, while a timing position wants seconds and nothing in the way of them. A live time display nobody can read at distance is decoration, not information.
Conclusion
Live time is simply time that keeps moving: a value recomputed from the device clock many times a second rather than a timestamp frozen at page load. The number travels from atomic clocks through NTP to your operating system, and the browser reads it with Date.now() and repaints it with requestAnimationFrame. That means a live time display is exactly as accurate as the machine it runs on, no better and no worse, so keeping the machine synced is the whole of the maintenance. Open the live clock to watch it tick, or browse the other displays on livetime.now.