A price difference needs a timing question first
Two saved prices can carry timestamps that look close while describing different stages of a data journey. One might be the venue’s event time; another might be when a vendor or your application received a message. This worksheet checks the recorded-time evidence for one spot/futures pair before a separate price comparison. It does not calculate basis, slippage, funding or a trading opportunity.
Keep the exact venue and instrument series beside each record. A December future is not a perpetual contract just because both screens share a base-asset label. The timing report cannot repair a product mismatch. Its narrow output is a gap between the supplied records, a conservative precision range and a list of conditions that prevent the chosen timing test.
The Singapore midnight boundary can split one pair across dates
Singapore’s National Metrology Centre describes Singapore Standard Time as UTC(SG) advanced by eight hours. For a Singapore research diary, late-afternoon UTC observations can therefore fall on the following local date. Keeping only the printed calendar day can separate records that are actually close together. Keep the complete timestamp and offset; the worksheet adds a Singapore display alongside the original.
The fictional pair crosses this boundary: 15:59:59.900Z on 20 October displays as 23:59:59.900 that evening in Singapore. The other record explicitly uses +08:00 and falls at midnight on 21 October. Subtracting calendar dates would suggest different days; comparing their represented instants gives only 100 milliseconds. Neither representation shows whether the source clocks were correct.
Sources: A*STAR National Metrology Centre — Time & Frequency.
Match the meaning before interpreting the subtraction
A field called time or timestamp is not self-explanatory. Record its documented meaning for each source. This worksheet has four labels: market event, vendor received, local received and unknown. They are your descriptions of the saved fields, not a claim that a particular venue publishes all four or uses these exact names.
If the two meanings differ or one is unknown, the timing classification is withheld. The represented timestamp subtraction remains visible as arithmetic, but it is not renamed network latency. Even two local-received times can come from different machines. The report leaves clock accuracy and actual synchronisation unknown rather than inferring them from a small number.
Visible digits do not establish the recording rule
A timestamp printed to a whole second might have been rounded, truncated, reformatted or copied from a screen. Those possibilities imply different uncertainty. The worksheet supports only two explicitly supplied truncation rules: whole seconds and whole milliseconds. Select unknown when the rule is missing or when the source rounds. Adding .000 does not recover lost information.
For a value known to be truncated to a second, the represented instant is the beginning of a one-second interval. A millisecond-truncated value has a one-millisecond interval. The tool uses closed outer bounds around these intervals. These deliberately conservative bounds include their upper endpoint; a boundary result may remain unresolved even when an exact half-open interval treatment could be tighter. They do not cover unknown clock error.
The example’s 100 ms is not a 100 ms accuracy claim
The spot timestamp represents an interval from 15:59:59.900Z up to an outer endpoint at .901Z. The futures timestamp represents an interval from 16:00:00.000Z up to an outer endpoint at 16:00:01.000Z. The smallest conservative distance is 99 ms and the largest is 1100 ms. The chosen 500 ms bound lies inside that range.
The result therefore says resolution_spans_chosen_bound. Reducing the displayed decimal places does not solve it, and increasing the tolerance merely changes your test. To narrow the range you would need better evidence about the recorded precision, not a more confident label. All values in this worked case are fictional; they are not an observation of Singapore markets.
| Quantity | Fictional result | Meaning |
|---|---|---|
| Recorded futures − spot | 100 ms | Subtraction of represented instants |
| Conservative minimum absolute gap | 99 ms | Lower outer bound |
| Conservative maximum absolute gap | 1100 ms | Upper outer bound |
| Chosen limit | 500 ms | Reader input, no recommended threshold |
| Classification | Resolution spans chosen bound | Recorded precision does not settle this test |
Three bounded results and a separate withheld state
When the largest outer distance is at or below your chosen limit, the pair is within the supplied gap bound under the stated assumptions. When the smallest outer distance is strictly above the limit, it is outside. Otherwise the resolution spans the chosen bound. These labels describe the record-time model, not whether a trade is safe or a price comparison is economically valid.
Missing field references, different meanings or an unknown truncation rule produce comparison_withheld. An absent precision rule leaves the numerical interval bounds unknown, not zero. A zero tolerance also does not prove two real events were simultaneous: equal printed times can still represent nonzero intervals and independent clock errors.
Preserve offsets and do not reinterpret unsupported timestamps
RFC 3339 describes explicit numeric offsets and their relationship to UTC. The worksheet accepts a limited timestamp subset with seconds, uppercase T and Z or a numeric offset, and at most millisecond precision. The original text and normalised UTC value are both exported. Equivalent offsets can describe the same instant; different-looking strings are not necessarily different times.
The restriction is deliberately narrower than the RFC: leap seconds, unqualified local time, date-only values and -00:00 are not accepted here. This does not mean those representations are universally invalid. Do not replace an unsupported field with Z to make validation pass. Preserve the original source and establish its convention before preparing a supported representation.
Sources: RFC Editor — RFC 3339, Date and Time on the Internet.
Use the report as a checkpoint, not a price signal
Save the report with the two source records and the documentation that supports your timestamp labels. It includes both instruments, venues, original timestamp text, UTC, Singapore display, precision rules and your chosen threshold. The worksheet does not fetch sources or save inputs to a server. Editing any input invalidates the earlier export until you inspect the new pair.
If the timing check is usable, a separate analysis still needs matching price definitions, quote and settlement units, contract terms and an appropriate data sample. One timing pair cannot establish a persistent market relationship. If the check is withheld or unresolved, keep that state visible in the research log instead of inserting an assumed zero gap or relabelling receipt time as event time.
Worked examples
Example 1
The fictional spot record is 23:59:59.900 in Singapore on 20 October, while the futures record is 00:00:00 on 21 October. Recorded futures minus spot is 100 ms. With the supplied millisecond/second truncation rules, conservative absolute-gap bounds are 99 to 1100 ms. They straddle the chosen 500 ms threshold, so the result is unresolved at that precision. Actual clock accuracy and live synchronisation remain unknown.
Inspect example inputs
{
"spot_venue": "DEMO spot venue",
"spot_instrument": "DEMO-BASE/QUOTE spot",
"spot_at": "2026-10-20T15:59:59.900Z",
"spot_kind": "market_event",
"spot_resolution": "truncated_millisecond",
"spot_reference": "DEMO field documentation: event time truncated to whole milliseconds",
"futures_venue": "DEMO futures venue",
"futures_instrument": "DEMO-BASE/QUOTE December future",
"futures_at": "2026-10-21T00:00:00+08:00",
"futures_kind": "market_event",
"futures_resolution": "truncated_second",
"futures_reference": "DEMO field documentation: event time truncated to whole seconds",
"max_gap_ms": "500"
}Questions about the method
Does within the bound prove live synchronisation?
No. The result assumes the supplied field meanings and truncation rules and does not measure clock error or query a live feed.
Can I enter a received time opposite an event time?
You can preserve them, but the classification is withheld because their meanings differ. The subtraction is not automatically latency.
What if I only know the displayed digits?
Choose unknown truncation. The tool must not infer truncation from the number of visible digits.
Primary sources and scope
- A*STAR National Metrology Centre — Time & FrequencyChecked 2026-10-20. Singapore Standard Time is UTC(SG) advanced by eight hours. Verified from indexed primary text; direct read showed a JavaScript challenge. No live clock accuracy claim.
- RFC Editor — RFC 3339, Date and Time on the InternetChecked 2026-10-20. Explicit offsets and UTC representation. Worksheet uses a documented narrower subset and does not claim complete RFC support.
Examples explain a method. They do not predict prices or establish where a trading service is available. Check the named source before relying on future schedules.