The geo-interoperability KB makes a point of stating that geometry does not fully define a measurement target — two systems can agree on a polygon and still disagree about what counts as "inside" it. The temporal side has the direct analog: two systems can agree on the exact same canonical (ISO week x slot) coordinate and still be measuring two different things. Getting the slot right is necessary; it is not sufficient.
UTC-canonical vs. local experience
The canonical unit of this KB is UTC. But almost every human-meaningful temporal concept — primetime, lunch, the morning commute, "8pm" — is a local experience, defined relative to the sun and the clock on the wall, not relative to Greenwich. Holding the UTC slot fixed across markets does not hold the local experience fixed: slot 69 (Wednesday 21:00 UTC) is prime-time evening in New York, mid-afternoon in Los Angeles, and the middle of the Thursday morning commute in Mumbai. A cross-market comparison that joins on the bare UTC slot and interprets the result as "the same daypart everywhere" has silently substituted a UTC fact for a local claim.
Comparing behavior "at the same UTC slot" across zones answers a UTC-canonical question. Comparing behavior "at 8pm local" across zones answers a different, local-experience question — and requires computing a different UTC slot per zone per week, not reusing one slot for every market. Declare which question is being asked before running the comparison; see half-hour-offset-zones and Daypart to slots for how a local band is translated into per-zone UTC slot-sets correctly.
This is the direct temporal analog of requested-vs-executed geography: the local experience is what was meant; the UTC slot is what got executed and stored. See Requested vs. executed time for the mechanics of that resolution and Resolution and grain for choosing between UTC-indexed and local-indexed reporting up front.
Event, ingestion, and report time
A single record commonly carries three distinct instants, and reports routinely mix them without saying so:
- event time
- When the thing actually happened — an impression served, a door opened, a purchase completed.
- ingestion time
- When the record arrived in the measuring system's pipeline, which can lag event time by seconds (streaming) to days (batch).
- report time
- When the aggregate containing the record was computed or published, which can lag ingestion further.
Each of the three resolves to a different slot in general, and the gap
between event time and ingestion time is rarely constant — batch
pipelines, retry queues, and offline device sync all introduce variable
lag, so "ingestion slot" is not a fixed offset from "event slot" that can
be corrected after the fact with a single constant. Any slot-indexed
dataset must declare which of the three timestamps defines the slot
(event-vs-ingestion-vs-report-time); the default in this KB is event
time, but a system built on top of a feed that only reliably provides
ingestion time must say so explicitly rather than label the result "event
slot" by convention.
Attribution-window time
Attribution introduces a fourth candidate: when a conversion is credited
to an earlier impression under a click-through or view-through attribution
model, the "time" of the conversion event is ambiguous between the
conversion's own timestamp and the timestamp of the impression it is
attributed to (attribution-window-time). A conversion that happens at
23:50 on Friday but is attributed to a Tuesday-morning impression could
reasonably be slotted either as "Friday night" (event time) or "Tuesday
morning" (attributed time) — and a report that does not declare which it
used cannot be reconciled against a second report using the other
convention, even though both reports are internally consistent. State
whether the slot is the conversion's own event time or the attributed
impression's time, and retain both fields rather than discarding one.
No silent rollup, and slot-boundary dedup
Two measurement-specific failure modes round out this page, both of which
are about what happens after a correct slot has already been computed.
No-silent-temporal-rollup:
a buyer who requests hourly delivery or reporting and receives a report
silently computed at day or week grain has been given an answer to a
coarser, unstated question — see
Resolution and grain for the discipline
this requires at every grain choice in the pipeline, not only at the
final report.
Slot-boundary dedup: an event with
duration — a session, a video view, a linear ad airing — that spans a
:00 boundary can be double-counted (attributed to both slots it touches)
or dropped (attributed to neither, if the assignment rule implicitly
assumes instantaneous events) unless the assignment rule is declared:
start-time, end-time, or overlap-weighted apportionment, deduplicated by
(key, slot) so a single spanning event contributes to a slot's count at
most once under whichever rule was chosen.
The core tension, stated plainly
Two platforms can both report "traffic at slot 69, week 2026-W30" and mean genuinely different things: one measured event time from its own ingestion pipeline with a 4-hour batch lag folded in unnoticed; the other measured attributed conversions credited back to a click that happened in a different slot entirely. The slot matching perfectly is not evidence the measurements agree — it is only evidence that both systems can compute the same arithmetic. Reconciling two slot-indexed datasets requires reconciling the semantics behind the slot — which time defines it, whether it reflects UTC-canonical or local-experience intent, whether attribution shifted it — before the numbers themselves can be compared, exactly as the geo KB requires reconciling what counts as inside a polygon before two coverage numbers can be compared, not just agreeing on the polygon's coordinates.