A successful refresh does not by itself establish that the underlying data changed. The timestamp attached to a source value, the time a server received it and the time a screen requested it can differ. I followed those distinctions through a quote server and its screen adapter.
The starting question was whether delayed market updates could still count as real time. Connection success and the fixed demo belong to an earlier stage; the guide and source inspected for this article used incoming observations for virtual calculations. This article follows the timestamps through that path rather than assessing returns.
Place source time beside receipt time
On the normal server path, asOf describes the selected source observations and fetchedAt is recorded after the server receives the provider response. Receiving data later does not move its original timestamp forward. A refresh-success label needs room to explain that distinction.
The inspected screen code presents source time and delay separately from receipt status. If a request fails and earlier data for the same market remains available, its status says it is showing earlier values while reconnecting. Numbers remaining visible do not establish that a new request succeeded.
A field name alone does not establish provenance. When fetchedAt is absent from a payload, the screen adapter substitutes its current time. That field is therefore not always an untouched server receipt record. Inspect the normal transfer path and the missing-value fallback.
Explore the implementation
Synthetic timing relationship · not a market record
Synthetic timing example, not a captured market response
source asOf = 12:00
server fetchedAt = 12:03
screen refresh = 12:04
A refreshed response alone does not move source asOf to 12:04.Cache reuse and a newer source observation need separate evidence
The server cache is configured for 30 seconds and the screen schedules requests every 60 seconds. A valid cache returns the stored value. Its fetchedAt stays with that value rather than changing to the current time on every HTTP response, preserving a clue about when the server acquired it.
A true cached flag does not always mean a response sat in storage. If a request for the same key is already in flight, callers wait for and share its result through a branch that also marks cached true. The flag identifies reuse in this implementation; it does not alone establish source age or request latency.
Those two intervals are code settings, not measured screen-request cadence or guaranteed delivery times. I did not add 30 seconds to 60 seconds and present the sum as an end-to-end delay bound. Source timestamps and actual request outcomes still need examination.
One summary timestamp cannot establish that every item is current
The server takes the latest valid source timestamp among selected items as asOf and the earliest as oldestAsOf. It does not assume that every item shares a timestamp. A recent summary can coexist with an older observation elsewhere in the list.
The screen adapter prefers oldestAsOf as its displayed basis. If absent, it falls back to the response asOf or the latest item timestamp. I read the older-first choice alongside those fallbacks. Neither establishes that every item has a verified timestamp.
The server excludes empty or invalid times from the aggregate. A summary timestamp therefore cannot establish the age of an item with no source time. A similar list should show the aggregation rule alongside items whose timestamps are missing.
A repeated response should not automatically become another calculation
The virtual engine builds its snapshot key from symbols and source timestamps, excluding server fetch time. If that key remains in the processed record, the same snapshot returns the existing ledger. Receiving a response again is not enough to create another virtual fill from the same input.
The engine compares the supplied observation time with the source timestamp and checks for regression behind previously known data. This is not a check against the current wall clock on every request. Following the screen’s supplied values through the comparison exposes that distinction.
Existing test definitions cover returning the same ledger for the same snapshot and preventing older data from regressing a marked value. I read those definitions without running product tests or requesting quotes. This is not a claim of permanent exactly-once behavior across all later runs beyond the retained processed record.
A zero-minute delay field is not a real-time guarantee
The current delay-label function reports an unconfirmed delay when no finite delay value is available. For a value of 0 or less, it pairs zero displayed minutes with a warning that real time is not guaranteed. One provider metadata number does not describe the entire connection and delivery quality.
The server also marks its response as unofficial and potentially delayed, with ticks and order-book data outside its declared capabilities. This describes what the current code emits. Writing this article did not test actual provider latency, current market status, service guarantees or real trading connections.
For another data-backed workflow, inspect the value, source time, receipt time and status together. Identify retained values after refresh failure and timestamps supplied by fallback before writing just updated. The related article asks whether the inputs needed to evaluate a condition are available.