Every piece of market data has at least two times attached to it. One is when the thing happened at the source. The other is when your system received it. Most confusion about how fresh a number is comes from showing one and meaning the other.
Event time
Event time is set by the source. A trade printed at this moment. A quote was updated at that one. A block was produced at a given second. It is the time the fact became true, and it does not depend on who is listening.
Arrival time
Arrival time is set by the receiver. It is when the message reached your system, or when your system last asked and got an answer. It is always later than event time. The gap between them is delay: network transit, the source’s own batching, the interval between polls. Latency in retail trading covers where that delay comes from.
Why one is not enough
Show only arrival time and a stale value looks fresh. A system that fetched an hour-old figure a second ago can truthfully say it updated one second ago while displaying something an hour old. This is the most common way a screen misleads without containing a single wrong number.
Show only event time and a quiet market looks broken. A value last changed an hour ago may be perfectly current if nothing has traded since. Without the arrival time there is no way to see that the system checked a moment ago and found it unchanged.
The two together resolve it. Old event time with recent arrival time is a quiet market. Old event time with old arrival time is an unknown. A feed that stops versus a market that is quiet builds on that pair.
When the source gives no event time
Some sources publish a value with no timestamp of their own. Then the receiver knows only when it fetched the value, and has to say so. Stamping that value with the fetch time and presenting it as the time of measurement would claim knowledge the system does not have. The honest label is that the value was retrieved at this time and its true age is at least that. Measured, retrieved or unknown is about exactly this distinction.
Ordering and clocks
The two times also matter for building history. Messages can arrive out of order. If a system files each one by arrival time, a late message lands in the wrong candle. Filing by event time puts it where it belongs. That is why a candle may still change slightly just after its interval ends. How a candle is built goes further into this.
Event time comes from the source’s clock and arrival time from yours. If the two clocks are not synchronized, the computed delay can come out wrong, even negative. Systems that care keep their clocks disciplined against a common reference and treat a negative age as a sign of clock trouble.
Where NoVo shows it
On the MCP & API, every reading carries as_of, age_seconds and as_of_kind. The kind says whether the time is a measured one, a retrieved one or unknown. Why we publish age_seconds explains the reasoning.