Knowledge Base

Overview

The time page at truestamp.com/time is a full-screen display of the current Truestamp server time, built to be looked at rather than merely visited: on a wall monitor, in a stream overlay, or in the background of a video shoot. Around the large 24-hour time it composes five instruments: a measurement of how far the viewing device’s own clock deviates from the server, a sub-second subdial that can subdivide each second at common camera frame rates, the latest public entropy beacon in hex, a QR code linking to that beacon’s public page, and an ambient rail down the left edge streaming external entropy captures as they happen. Together these let a recording of the page carry layered, independently checkable timing evidence. The page is available to anyone, signed in or not, and works in light and dark themes.

Time display and timezone modes

The clock shows hours, minutes, and seconds, in 24-hour form by default or a 12-hour option (the beacon’s mint time follows the same choice), in one of two timezone modes:

• UTC (the default): Coordinated Universal Time, the reference frame the Truestamp ledger itself records.
• Local: a signed-in visitor’s preferred timezone from their preferences; if no preference is set (or the preference is UTC), the browser’s own timezone is used instead. Anonymous visitors always get the browser’s timezone in this mode.

Beneath the time sit three small cards: the measured device offset, the date written out in the visitor’s own language, and the active timezone as its standardized short code (UTC, EDT, PDT, or a GMT offset where the zone has no letters). Beyond digits and units the display carries almost no words, so it reads the same in every language.

The displayed time is the server’s time, not the device’s: the page continuously measures the offset between the two (see the next section) and renders device time + measured offset on the viewer’s own screen many times per second. The server never pushes a tick: it sends only new beacons (about once a minute), entropy captures as their sources publish, and settings changes, while the ticking itself happens entirely on the viewer’s device.

Device clock delta

Every five seconds the page sends a ping over its live connection carrying the device’s current time; the server answers with its own timestamp. The page then applies the classic NTP midpoint calculation: the server’s clock is compared against the midpoint of the round trip, which cancels network delay to the extent the two directions are symmetric. Successive samples are smoothed to damp jitter.

The result appears in the offset card beneath the time, reporting the device’s clock relative to the displayed server time in sensible units (milliseconds up to days), colored by health: green under 500 ms of disagreement, amber under one second, red beyond. The value glows softly each time a measurement lands, so the reading is visibly alive; when verification stops, the card dims to the age of the last measurement and the page degrades to a stale state rather than pretending (see the next section). Accuracy is bounded by how asymmetric the network path is: typically a few milliseconds on a local network and tens of milliseconds across the public internet, so the delta is a health indicator, not a laboratory instrument.

Sync states

The page holds itself to a rule: it presents its time as the server’s only while it can currently verify it. Alongside the offset measurement, the server sends a once-a-second heartbeat carrying its own clock, and a small state machine gates every instrument on the two signals:

• Syncing: before the first offset measurement lands, the digits show --:--:-- rather than ever showing the device’s own unverified time.
• Synced: measurements and heartbeats are both fresh; the page displays normally.
• Stale: heartbeats or measurements have stopped arriving, or the device’s clock stepped and the corrected offset is not yet confirmed. The clock keeps ticking on the last verified offset, but the display dims, the delta line stops showing any number at all, and a warning banner appears.
• Offline: the connection itself is down. The same degraded display with a connection-lost banner; after reconnecting, the page re-measures before declaring itself synced again.

A verified offset also has a shelf life. The dimmed, coasting display covers only brief disruptions: after fifteen seconds of continuous stale or offline state (or on returning to a tab whose last measurement is long overdue) the content area stands down entirely. Every instrument, the beacon and QR included, is replaced by a single prominent warning card naming the cause, while the page header stays usable, because the page exists to show verified server time, never a free-running device clock. The moment a fresh measurement lands, the full display returns. If the live session cannot re-establish itself once the server is reachable again, the page reloads itself instead, so an unattended wall display always recovers without a manual refresh.

The banner never fades with the idle controls, so a recording of an unverified clock carries the warning on its face, and the tick sound is silenced outside the synced state so the audio track stays as honest as the picture. A stepped device clock (a laptop resuming, a manual change) is corrected immediately on the next measurement rather than smoothed away, and measurements whose round trip is too slow to be trusted are discarded.

Sub-second subdial

The middle of the display holds a chronometer-style dial: a large ring of dots subdividing the current second, with the current index printed in the middle.

• Tenths (the default): ten dots and a .7-style readout, calm enough for human eyes.
• Frame-rate modes: 24, 25, 30, 50, or 60 dots, one per frame period of the matching camera rate, with the index shown timecode-style (:17) and the rate labeled inside the dial. Each mode is an exact integer subdivision of the wall-clock second, so the ring fills once per second and resets on the second boundary, in lockstep with the displayed time.
• Off: the subdial can also be hidden entirely, leaving only the hours-minutes-seconds display.

The ring exists because digits fail on camera. A camera integrates light over its shutter interval, so any glyph changing faster than the exposure smears into an unreadable blur, and rolling shutter can capture a digit half-changed. A dot ring encodes sub-second time as position instead: a position survives motion blur (the blur streak’s center is still the time) and turns rolling-shutter artifacts into an interpretable seam. When the ring’s rate matches the camera’s, footage of the page advances the ring by about one dot per captured frame.

Beacon and QR code

The lower left of the page shows the beacon: the newest finalized Truestamp block hash, printed as eight four-byte hex groups and labeled with the minute it was minted in whichever timezone the clock is showing. When a new block finalizes, about once a minute, the fresh hash blooms in with a brief glow, so a change reads as a new fact rather than a silent repaint. A QR code in the lower right, sized to be scanned from across a room, leads straight to the verification page for that beacon, since checking the value is what someone scanning a screen or a recording is there to do; it renders as dark modules on a white tile so ordinary scanners read it in either theme.

Because a beacon value cannot be known before its block is minted, its presence in a frame is evidence the frame was recorded no earlier than that minute, and anyone can later confirm the value against the public beacon chain. See public entropy beacons for what a beacon commits to and public randomness for the wider fairness uses.

Entropy rail

On larger displays, freshly captured entropy observations drift down the page’s left edge in three quiet lanes, one per source, ordered by publish frequency: Stellar ledgers (roughly every five seconds), NIST beacon pulses (each minute the beacon publishes), and Bitcoin blocks (roughly every ten minutes). Each entry is a small source label and the last eight hex characters of the value that source just published, linking to that observation’s public page in a new tab so anything seen on the rail can be checked at the source, and captures that arrive together simply appear side by side in their lanes. Every capture that arrives is shown: each lane’s drift speed is matched to its source’s cadence, so the Stellar lane flows quickly while the NIST and Bitcoin lanes take about one beacon interval to traverse the screen. A new capture arrives bright and dims gradually across its traverse, so within a lane brightness reads as age and the newest entry is always the most legible. When the next beacon is minted, a tinted front sweeps the lanes down into the beacon block as its fresh hash blooms in: the drained values are, in fact, what that block folded into its Merkle tree alongside submitted items.

The rail earns its place in a recording. Its values cannot be known before their sources publish them, its motion is continuous rather than stepped, and its once-a-minute drain is synchronized with the beacon changing, so a frozen, looped, or replayed capture of the page disagrees with itself in one more independent way. On small screens the rail is hidden, and with reduced motion enabled each lane becomes a short static list of its latest observations that still updates as captures arrive.

Display controls and URL state

The controls fade out after a few seconds of idle pointer, leaving a clean panel suitable for a wall display, and return on any movement (on a touch screen, a tap). A question-mark control opens this document in a new tab, so consulting the help never navigates the clock away. Each control also has a keyboard shortcut, and every setting is carried in the page address so a configured view can be bookmarked or loaded by a streaming overlay. Signed-in visitors also get their settings remembered across visits: any control changed away from its default is stored with their account and restored on the next load, with anything spelled out in the address winning over the stored choice for that setting. Anonymous visitors keep the address and the controls:

Setting	Address parameter	Shortcut	Default
UTC or local time	tz=local	T	UTC
12 or 24 hour time	hours=12	H	24-hour
Sub-second mode	tick=24, 25, 30, 50, 60, or tick=0 to hide	S	tenths
Device delta line	delta=0 to hide	D	shown
Beacon	beacon=0 to hide	B	shown
Beacon QR code	qr=0 to hide	Q	shown
Entropy rail	feed=0 to hide	E	shown
Second tick sound	sound=1	M	off
Full screen	(not in the address)	F	off

For example, truestamp.com/time?tick=30&qr=0 opens the clock subdividing at 30 frames per second with the QR tile hidden.

The tick sound, when enabled, is a short square-wave burst that rises exactly on each top of second (as measured against the server clock) and lasts about a tenth of a second. Browsers permit audio only after an interaction with the page, which the enabling click provides.

What a recording can evidence

Filmed as a backdrop, the page layers three independent timing signals across three time scales:

• Minutes: the beacon. The hash on screen did not exist before its block was minted, so every frame containing it was recorded no earlier than that minute, and a clip longer than a minute must show successive beacons in the right order, each verifiable against the public chain.
• Seconds: the clock. The visible time must advance monotonically and consistently with the beacon minutes across the whole clip.
• Frames: the subdial ring. At a matching rate, consecutive video frames should differ by about one dot. A frozen ring across advancing frames suggests a freeze or duplicated frames, a multi-dot jump suggests dropped frames or a cut, and a wrong cadence suggests retiming.

With the tick sound enabled, the recording’s audio track carries the same second boundaries as the picture, adding a cross-check between the two: each audible tick should coincide with the visible second rollover, so audio and video edited independently, or drifting relative to each other, fall out of alignment.

The entropy rail adds a continuous texture across all three scales: its values were unknowable until seconds before they appeared, its drift moves in every frame rather than in steps, and its once-a-minute drain must coincide with the beacon changing, so a splice or retime has yet another independent signal to keep consistent.

An edit that escapes all three checks must regenerate a consistent ring, clock, and beacon sequence in every affected frame, including plausible motion blur and rolling-shutter behavior, against hash values the editor could not have known in advance. The page cannot make tampering impossible; it makes undetectable tampering substantially more expensive.

Limitations

• The evidence is about timing, not content. The page says nothing about what else appears in a video or whether that content is genuine; it constrains when the screen showing the page was recorded.
• One direction only. The beacon gives recorded-no-earlier-than. The clock and subdial support consistency checks, but nothing on screen can prove a recording was not made later while replaying a captured screen; corroborating a latest-possible time needs evidence from outside the page.
• No synchronization with the camera. The page, the monitor, and the camera each run free, so one-dot-per-frame correspondence is statistical, not exact per frame.
• Fractional broadcast rates beat slowly against the dial. The frame modes subdivide the true second exactly, while NTSC-lineage cameras run at 30000/1001 (about 29.97) and 24000/1001 (about 23.976) frames per second. Against the 30 mode this produces one extra-or-missing dot step roughly every 33 seconds, and against the 24 mode roughly every 42 seconds: a periodic, predictable beat, unlike the abrupt discontinuity of a splice. European 25 and 50, true 24, and the true 30 and 60 common on phones and screen recorders match exactly.
• The monitor’s refresh is the floor of precision. Every visual update lands on the display’s refresh grid (about 16.7 ms at 60 Hz), so 60 subdivisions per second is the honest ceiling on a 60 Hz display, and finer claims would be false precision. This is also why the page shows no raw milliseconds.
• The delta is advisory. Network asymmetry bounds the offset measurement, so the delta line indicates clock health rather than certifying millisecond accuracy.

Citations

1. RFC 5905: Network Time Protocol Version 4. Source of the midpoint offset calculation the device delta measurement applies over the page’s live connection.