Give each timestamp a different job
A quote can carry a provider event time, reach your device later and appear in a screenshot later still. A timestamp printed on the screenshot belongs to the capture unless its source says otherwise. It cannot establish when the underlying market observation was generated.
Start with three separate fields: the source's stated event timestamp, your receipt timestamp and your display or capture timestamp. Retain the provider, instrument, currency and response type beside them. Public quote and trade schemas illustrate different observations; do not assume a field present in one response must be present in another.
If the source supplies no event time, mark event-to-receipt age unknown. A sequence or update identifier can help order records under the provider's rules, but it is not automatically a Unix timestamp. A locally added receive time does not fill the missing event-time field.
Keep the Singapore date boundary
Use this invented record: a source event is labelled 2026-10-21T16:00:00Z, receipt is 2026-10-22T00:00:00.200+08:00 and capture is 2026-10-22T00:00:05+08:00. The different written dates are compatible. Singapore is eight hours ahead of UTC in these supplied instants.
Under an explicitly assumed synchronised-clock model, source-to-receipt is 0.200 seconds, receipt-to-capture is 4.800 seconds and source-to-capture is 5.000 seconds. Those are arithmetic results from fictional inputs, not a measured feed delay or a statement about any provider's performance.
| Interval | Fictional result | Evidence limitation |
|---|---|---|
| Event to receipt | 0.200s | Requires comparable source/device clocks |
| Receipt to capture | 4.800s | Requires a stable local measurement |
| Event to capture | 5.000s | Does not prove an executable price |
An explicit offset is not proof of an accurate clock
Offsets let you represent an instant without confusing Singapore midnight with the previous UTC date. They do not establish that two machines agree on the time. Keep clock-synchronisation evidence or its absence in the log. If the source clock offset is unknown, the cross-machine interval is a nominal difference, not a verified latency.
For intervals measured on one device, a monotonic clock can avoid jumps caused by wall-clock corrections. Its reference value is not a calendar time. Retain the elapsed interval and the associated wall-clock record separately rather than formatting a monotonic reading as a fabricated UTC timestamp.
A negative nominal age is a clock problem to retain
If the source label appears later than your receipt label, keep that negative nominal difference in the evidence note. Do not clamp it to zero and call the quote perfectly fresh. It can indicate a clock offset, a wrongly interpreted unit, a date conversion error or a mismatch between records; the subtraction alone does not identify which cause applies.
Check whether a numeric timestamp is documented in seconds, milliseconds or another unit before converting it. Preserve the original value alongside the interpretation and its source. A longer integer is not a reliable unit detector. Similarly, a missing source timestamp and a genuinely supplied zero-valued field are different cases. The useful output is the identified limitation, not a fabricated age that happens to fit your threshold.
Record the rule before calling a quote stale
Freshness is also a policy question. A hypothetical one-second threshold and a ten-second threshold classify the same five-second-old observation differently. Save the threshold, the event type it applies to and the clock assumptions used; this article does not prescribe a trading threshold.
Finish with a bounded conclusion: a supported interval under stated assumptions, or an unknown interval with the missing field named. A quote-age log does not prove a fill could have occurred at that price, that a signal was timely or that an account actually traded.
The optional link below leads to this site's separate crypto signals and Telegram updates offer. The record method is usable without that offer. It does not independently verify the offer, establish country eligibility or turn the teaching example into an actual transaction.
Primary sources and scope
- Binance Developer Docs: Spot market data
Illustrative public trade and quoted bid/ask fields; no live data or platform eligibility established. Checked 2026-10-21. - RFC 3339: Internet timestamps
Full dates and explicit numeric offsets; a timestamp representation does not prove clock synchronisation. Checked 2026-10-21. - Python documentation: monotonic clocks
Monotonic-clock differences measure intervals; the reference value is not a UTC calendar timestamp. Checked 2026-10-21.