Hypothetical worked example, not a measured incident. A 90-second gap between the recording’s program start and the first badge scan of the keynote is the kind of discrepancy that survives load-in because no single system is wrong. Each subsystem is keeping time against a different reference frame, and nobody wrote down which frame the event agreed to use. This article sets out a time-sync standard for the Technical Director or Event Systems Lead: one authoritative source per event, UTC-with-offset logging everywhere, a reconciliation check before doors, and a documented tolerance for scan data. Every fix below is reversible and testable before the room fills.
Why the clocks disagree is a systems problem
Streaming, recording, and badge-scan systems do not share a time base by default. That is not a defect in any one of them; it is what their governing specifications require.
- NTP/UTC. The Network Time Protocol exists to convey timekeeping information from primary servers synchronized to national standards down to clients, and its algorithms are built to mitigate errors from network disruptions, server failures, and hostile actions (RFC 5905). Its output is a UTC calendar time.
- PTP/SMPTE epoch. SMPTE ST 2059-2 defines a Precision Time Protocol profile for time and frequency synchronization in professional broadcast environments, based on IEEE Std 1588-2008 (SMPTE ST 2059-2:2021). Its time base is not a UTC calendar timestamp: the PTP epoch is defined as 63072010 seconds before 1972-01-01T00:00:00Z (UTC). SMPTE ST 2110-10 builds on that model, specifying timestamping for video and audio streams so that time alignment across essence is possible, with streams referenced to a common reference clock distributed via PTP (SMPTE ST 2110-10:2022).
- Page-relative WebRTC stats. WebRTC statistics timestamps are expressed with DOMHighResTimeStamp and defined as Performance.timeOrigin + Performance.now() at the moment the information is collected (W3C WebRTC Stats). That is a time base anchored to the page, not a wall-clock UTC value. It cannot be compared to a UTC log without conversion.
ETSI TR 103 010 reviews exactly this landscape — timestamp-based synchronization methods in IP networks, including NTP and PTP — and asks whether their achievable accuracies meet end-user quality expectations for multimedia services such as video conferencing (ETSI TR 103 010). The report’s framing is the useful one for operators: the question is not whether a protocol is accurate in the abstract, but whether its accuracy is adequate for the service in front of you.
In the hypothetical 90-second case, the likely shape of the failure is mundane. The recording host was disciplined by an NTP source. The scan server was set to local time and never confirmed its offset. The streaming platform’s stats were page-relative and were exported without conversion. Three defensible configurations, one unusable correlation table.
What the standards actually say — and what they don’t
RFC 5905 describes NTPv4’s mitigation and discipline algorithms as extending potential accuracy to tens of microseconds with modern workstations and fast LANs. That is a statement about protocol capability under favorable conditions, not a guarantee for a conference network with a saturated uplink and a vendor switch that nobody documented. Treat published accuracy figures as ceilings to design against, not as outcomes to assume.
For log formats, RFC 3339 defines an Internet date/time format that is a profile of ISO 8601, and it states plainly that true interoperability is best achieved by using Coordinated Universal Time. It also specifies that timestamps carry a stated relationship — an offset — to UTC, with numeric offsets calculated as local time minus UTC. That is the whole argument for the logging convention below: a timestamp without an explicit offset is not a timestamp, it is a local reading with an implied assumption.
None of these sources tells you what tolerance is acceptable for badge-scan data at a conference. That is an operational policy decision, and the event team should set it explicitly rather than inherit it from a device default.
The leap-second trap
Leap-second handling is a concrete, documented divergence point between time sources. Google Public NTP serves leap-smeared time, using the technique to handle leap seconds without disruptive events, and it recommends that you do not configure Google Public NTP together with non-leap-smearing NTP servers (Google Public NTP).
The operational consequence: if one subsystem is disciplined by a smeared source and another by a non-smeared source, they will disagree by a known, bounded amount around a leap second. The sources establish that smearing exists and that mixing classes is discouraged. They do not establish a specific magnitude for your event, so do not put a number in the runbook you cannot derive. What you can do is name the class of source the event uses and record it, so that post-event reconciliation knows what offset to expect.
A time-sync standard for the Event Systems Lead
The standard has four parts. Each is testable before doors open and reversible if it fails the test.
1. One authoritative source per event
Designate a single time source for the event and write its identity into the runbook: hostname or address, whether it is leap-smeared or not, and who owns it. Every subsystem that will produce post-event data — recording, streaming, scan server, registration — is configured to that source or explicitly documented as an exception with its own reference. The exception list is the point. An undocumented exception is how the 90-second gap happens.
2. UTC with explicit offset and source ID in every log
Adopt one log-format convention across exports. A timestamp is only usable for correlation if it carries three things: the UTC instant, the offset that was applied, and an identifier for the source that produced it. RFC 3339’s requirement that timestamps state their relationship to UTC is the format basis; the source identifier is the operational addition that lets you reconstruct which clock you are looking at when two records disagree.
For WebRTC-derived stats, record the conversion explicitly. The page-relative timestamp is defined as Performance.timeOrigin + Performance.now(); if you export it alongside a UTC value, note the conversion method and the moment it was applied. Do not present a page-relative value as if it were wall-clock time.
3. A pre-doors reconciliation check
Before the room fills, compare the clocks that will matter after the event. The check is a comparison, not a correction: you are establishing the baseline offset between subsystems so that any later drift is measurable against a known starting point. Run it at load-in and again shortly before doors. Record both readings.
4. A documented tolerance for badge-scan timestamps
Scan data feeds continuing-education and continuing-professional-development credit rules and audit trails, which makes timestamp accuracy a compliance question, not just a reporting one. A vendor guide on event access control recommends setting time drift thresholds between device and server clocks — offering a 5-minute tolerance as an example — and recommends timestamping each scan with both local and server time so that credit records remain accurate after delayed syncs (Bizzabo, event access control and session scanning).
That 5-minute figure is vendor subject-matter input, not a standard, and it should be cited as one example rather than adopted as a rule. The event team should set its own tolerance, document the reasoning, and state it in the runbook. Dual timestamping — device time and server time on every scan — is the more durable recommendation because it preserves the evidence needed to reconcile after the fact.
Copyable artifact: pre-event clock reconciliation checklist
For the Technical Director or Event Systems Lead. Copy into the runbook and complete before doors.
EVENT CLOCK RECONCILIATION — [event name] — [date]
AUTHORITATIVE SOURCE
Host / address: ______________________________
Leap-smeared or non-smeared: __________________
Owner: _______________________________________
Documented exceptions (subsystem, its reference, why):
___________________________________________
___________________________________________
LOG FORMAT CONVENTION (all exports)
Required fields per record:
- UTC instant (RFC 3339 format)
- explicit offset applied
- source identifier
WebRTC-derived stats: conversion method noted: ______
RECONCILIATION READINGS
Subsystem Load-in reading Pre-doors reading
Recording host ______________ ______________
Streaming platform ______________ ______________
Scan server ______________ ______________
Registration system ______________ ______________
BADGE-SCAN TOLERANCE
Documented tolerance: _________________________
Basis for the figure: _________________________
Dual timestamping (device + server) enabled: ___
SIGNOFF
Checked by: ______________ Time: ___________
Reversible fixes when you find drift mid-event
If the pre-doors check shows a gap, the fix is to document it, not to silently correct it. Record the measured offset between subsystems and the time it was observed. If a subsystem can be re-pointed to the authoritative source without disrupting the live feed, do so and log the change with a timestamp. If it cannot, leave it running and note the offset so that post-event reconciliation has the number it needs.
After the event, reconcile records rather than rewriting them. The original timestamps, the offset readings, and the source identifiers are the evidence. A reconciliation table that maps each subsystem’s records onto the authoritative time base preserves the audit trail; editing the source records destroys it. This is the same discipline that applies to the room-to-chat handoff in hybrid events, where the failure mode is also a correlation problem between systems that each believe they are correct — see Why Hybrid Events Fall Apart at the Room-to-Chat Handoff.
FAQ
Can I just point everything at one NTP server and be done?
That gets you a shared reference for systems that speak NTP, but it does not resolve the PTP/SMPTE epoch difference or the page-relative WebRTC timestamp. The standard still needs the log-format convention and the reconciliation check, because the time bases differ even when the source is shared.
Is a 5-minute badge-scan tolerance acceptable?
It is one vendor’s example, not a standard. Set your own tolerance, document the basis, and enable dual timestamping so you can reconcile after the fact regardless of the threshold you choose.
What do I do if I discover drift after the event?
Reconcile, do not rewrite. Use the recorded offsets and source identifiers to map records onto the authoritative time base, and keep the original values as evidence.
Why does leap-second handling matter for a one-day event?
It matters when subsystems are disciplined by different classes of source. Naming whether your source is leap-smeared and recording it in the runbook means post-event reconciliation knows what offset to expect, rather than discovering it during a credit audit.