Decentralised News · Crypto Trading · Decision research
By Heath Muchena · Source review 2026-11-14 · Instrument version 1.0.0
What Matters
Two timestamps establish a strict order only under a defensible comparison model. Identify what each field marks, normalize its time representation and carry the clock error into an interval. If those intervals overlap or touch, this instrument leaves their order unresolved. Even a supported order does not establish why an event happened or who bears responsibility.
A trading agent reports a submission at 12:00:00.100. A venue record shows an event at 12:00:00.160. The apparent gap is 60 milliseconds. Before describing it as a measured processing delay, ask which clocks produced those values, what the fields mean and how far each clock could have been from the chosen reference.
This guide reconstructs the order that supplied timing evidence can support. It extends DN’s Decision Evidence Map with explicit clock-error intervals. The Request Timing Lab handles API authentication conditions, while the Signal Timing Inspector handles source and signal ages. Here, the decision is whether one particular recorded marker can be placed before another.
DN Evidence Block
Sources reviewed: 2026-11-14 · Evidence type: Current primary documentation and an original deterministic interval model. Editorial date: 14 November 2026, Africa/Johannesburg; source retrieval: 13 November UTC.
Scope: Two timestamped markers with explicit meanings, UTC representations and reader-supplied uncertainty bounds. No exchange ranking or dispute verdict.
- OpenTelemetry and Binance Spot documentation establish that similarly named time fields can describe different stages.
- RFC timestamp syntax and chrony documentation inform the format and clock-evidence checks.
- The interval equations, teaching limits and synthetic scenarios below are DN’s model choices, not a venue specification.
- Local examples test arithmetic and input handling; all clock values are invented.
Not established by this work: DN did not connect a trading account, measure a venue clock, inspect a private incident, establish an actual error bound or assess a legal claim.
Original DN instrument · version 1.0.0
DN Event Order Uncertainty Checker
Compare two timestamped markers using explicit UTC representations, signed clock corrections and total uncertainty bounds. Enter an established marker meaning and deliberate bounds, or keep the comparison unresolved. All calculations stay in this page.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Complete inputs or load an illustrative example.
Inputs are unverified declarations. Whole-millisecond resolution, years 2000–2100 and ±one-day offset / one-day uncertainty teaching limits. No clock synchronization, live API query, precision conversion, leap-second or smear model, probability estimate, shared-clock correlation, record authentication, causal proof or legal conclusion. The bound must apply at the relevant event and cover the stated marker.
1. State which two events you are trying to order
Start with a sentence another reviewer can test: “Did the connector’s recorded submission marker precede the venue’s recorded transaction marker?” Give each marker a short alias and retain the private record that defines it. A complete trade lifecycle can contain many events; a useful first comparison concerns one pair.
Separate the question about time from the question about identity. The references must first identify the intended records. If that relationship is unresolved, use the Decision Evidence Map before interpreting their chronology. A precise timestamp cannot repair a mismatched order or an unrelated attempt.
The DN checker takes the meanings you declare. It cannot discover whether a screenshot, log line or exported row belongs to the intended action. That boundary should accompany any saved result.
2. Separate event time from observation time
OpenTelemetry distinguishes a timestamp measured at the event’s source from the time a collection system observed that event. Those fields can be produced by different clocks. Their subtraction therefore requires both a meaning check and a clock comparison. [1]
For a trading pipeline, label a marker as narrowly as the evidence permits: a local instruction was recorded, a connector began sending, a venue reported a transaction, or a collector received a message. “The trade happened at this time” is too broad when the retained field describes only receipt.
If you want to infer an earlier event from a later capture point, you need a supported relationship and a bound for the intervening delay. Otherwise, compare the observation markers themselves and keep the underlying event time unresolved.
3. Read the timestamp definition for the exact API product
Binance Spot’s documented executionReport separates E for event time, T for transaction time, O for order creation and conditional W for working time. The presence of one field does not make it a substitute for all the others. [2]
| Documented Spot field | Meaning to preserve | Question still requiring evidence |
|---|---|---|
E | Event time | What event and status does this message describe? |
T | Transaction time | Does this particular report describe a fill or another update? |
O | Order creation time | Which order and attempt does the row identify? |
W | Working time, when the order is on the book | Was this conditional field actually present? |
This is one product’s documentation, not a cross-exchange field dictionary. Preserve the original field name, product and schema version in your own evidence. Do not infer a missing fill, funding or liquidation marker from a nearby update.
4. Normalize units and offsets before comparing values
Binance Spot documents millisecond defaults for JSON timestamps; OpenTelemetry’s log timestamp type uses nanoseconds since the Unix epoch. A number’s magnitude is a clue, but the documented type should govern its interpretation. [1][2]
For textual timestamps, retain a complete date and an explicit UTC representation or numeric offset. RFC 3339 defines the relevant date-time grammar, including fractional seconds and offset syntax. [3]
The checker intentionally accepts a narrow profile: YYYY-MM-DDTHH:mm:ss.SSSZ or the same format with ±HH:MM. It accepts years 2000–2100 and whole milliseconds. It rejects bare epoch numbers, local times without offsets, impossible dates and leap-second syntax. These are tool boundaries, not claims that other representations are invalid. Preserve a more precise original; any conversion must include its rounding uncertainty.
5. Translate the clock correction’s sign explicitly
This instrument defines the signed offset as clock minus UTC. A value of +20 ms means the clock reads 20 milliseconds ahead of the reference, so the corrected centre is the reported timestamp minus 20 milliseconds. A negative offset moves that centre later.
Do not paste a monitoring field into the box solely because its name includes “offset.” Chrony distinguishes the system clock’s remaining correction from the last measured local offset and other tracking values. Their reference points matter. [5]
Write the conversion rule beside the retained clock evidence. If you cannot determine the sign or reference, choose unknown. A guessed zero creates a clean-looking timeline without establishing a usable correction.
6. Use a defensible bound for the event’s time
A clock can show a stable small measured offset while still carrying error from asymmetric network delays. Chrony’s accuracy discussion explains why delay, dispersion and remaining system correction matter. A small average or a current “synchronized” state does not establish the error at an earlier event. [4]
Ask the clock operator for the contemporaneous evidence and its assumptions. Chrony’s documented accuracy bound also assumes the primary time source is correct. Treat that condition as part of the evidence. [5]
The checker’s total uncertainty covers whatever error remains around the corrected marker, including relevant timestamp precision and capture assumptions. It expects a bound, not a standard deviation or a 95% confidence interval. A fractional-millisecond bound must be conservatively represented at the tool’s whole-millisecond resolution. If the total cannot be supported, retain unknown.
7. Keep wall-clock comparisons separate from elapsed timers
An elapsed timer can answer how much time passed within its supported clock domain. A wall-clock timestamp aims to locate an event on a shared date-time scale. The W3C High Resolution Time Working Draft distinguishes a monotonic time source from system-clock adjustments; its status remains a Working Draft. [6]
Do not combine a browser performance value, a Unix timestamp and a venue timestamp as if they already share one origin. Preserve any mapping and its uncertainty. Likewise, a later successful clock check cannot be substituted for the historical evidence you need.
The DN checker does not synchronize clocks, reconstruct a monotonic-to-UTC mapping or model leap smearing. If two events share correlated clock error, its separate intervals can be conservative. It does not claim to extract every ordering that a richer trace might establish.
8. Compare interval edges and preserve ambiguous results
For a reported timestamp t, signed offset o and total uncertainty u, DN uses the closed interval [t − o − u, t − o + u]. This is an original comparison model built from your declared bounds.
Marker A strictly precedes B only when A’s latest possible time is earlier than B’s earliest possible time. The reverse condition establishes B before A under the same assumptions. A shared endpoint or an overlap leaves strict order unresolved.
In the synthetic first example, A’s corrected interval is 12:00:00.040–12:00:00.120 UTC. B’s is 12:00:00.100–12:00:00.220 UTC. The intervals overlap even though the recorded values differ by 60 milliseconds. The possible value of B minus A runs from −20 to +180 milliseconds. No single measured latency follows from those inputs, and overlap does not establish that the events were simultaneous.
9. Report the supported ordering and the remaining question
Use a conditional statement: “Within the supplied bounds and stated marker meanings, A precedes B by at least 120 milliseconds.” Attach the definitions, correction convention, bound provenance and unresolved assumptions. For an overlap, say which additional clock or capture evidence could narrow the comparison.
Message and process relationships can establish a partial ordering without relying only on wall-clock readings. Lamport’s work formalizes that distinction; it does not make every pair comparable. [7]
A timestamp-based order is still separate from a causal explanation, the completeness of the record and any contractual or legal conclusion. The checker does not decide whether an order executed correctly, whether a platform breached a duty or who should prevail in a dispute. Its useful output is a bounded chronology claim that another reviewer can inspect.
Methodology, limitations and corrections
DN designed a deterministic comparison of two closed UTC intervals. For each marker, the centre is the normalized timestamp minus the declared clock-minus-UTC offset. Its lower and upper endpoints subtract and add the total uncertainty. If both bounds and marker meanings are supplied, the possible B-minus-A interval is [B_lower − A_upper, B_upper − A_lower]. A strictly positive lower endpoint supports A before B; a strictly negative upper endpoint supports B before A. Otherwise, strict order stays unresolved.
This uses all combinations permitted by the separate bounds. It does not assume a statistical distribution or independence, and it does not model constraints from correlated clocks. A supported order is conditional on the entered bounds being valid. Unknown evidence and missing numbers are distinct: selecting an unknown bound preserves uncertainty; declaring a bound while leaving its required numbers blank is an input error.
The displayed scenarios are invented, hand-checkable teaching cases. Local validation checks overlap, endpoint equality, reversed corrections, equivalent UTC representations, missing evidence, invalid dates and unsupported precision. Those checks demonstrate calculation and input behavior, not the correctness of real trading records.
For corrections, identify the claim, source and date when contacting Decentralised News. A new record-creation timestamp does not refresh its underlying evidence.
Change log: version 1.0.0, 2026-11-14. Initial documentation review, original instrument and labelled examples.
Frequently asked questions
Does an earlier recorded timestamp prove an event happened first?
Only if the relevant meanings and clock evidence support that comparison. A later-looking timestamp from a slow clock may represent an earlier event. This checker reports strict order only when its declared uncertainty intervals are disjoint in the required direction.
What should I enter if I do not know the clock error?
Select unknown for that marker’s bound. Do not use zero as a placeholder. The instrument will preserve an unresolved order instead of inventing a correction or an error allowance.
Can I use a 95% interval or an RMS offset as the total bound?
Those quantities have different meanings from a hard enclosing bound. The instrument does not convert them. Obtain a supported bound and its assumptions, or keep the result unresolved.
Do touching intervals establish simultaneous events?
No. Touching or overlapping intervals do not establish a strict order from this model. They also do not prove simultaneity. More specific evidence may resolve the pair.
Can the output decide an agent-trading dispute?
No. It is a conditional timing comparison of entered markers. It does not authenticate evidence, assess causation, interpret contracts or determine responsibility.
Primary sources
- OpenTelemetry — Logs Data Model. Distinguishes source event Timestamp from collection-system ObservedTimestamp; both have explicit epoch-nanosecond types. Reviewed 2026-11-13.
- Binance Spot API — User Data Streams. Documents executionReport event, transaction, creation and conditional working-time fields; JSON timestamps default to milliseconds. This is documentation, not a live account test. Reviewed 2026-11-13.
- RFC 3339 — Date and Time on the Internet: Timestamps. Date-time syntax, numeric UTC offsets, fractional seconds and calendar restrictions. The DN tool intentionally supports a narrower millisecond profile. Reviewed 2026-11-13.
- chrony — Frequently Asked Questions, section 7.2. A stable measured offset can still contain asymmetric-network error; root delay, dispersion and remaining correction contribute to estimated clock error. Reviewed 2026-11-13.
- chrony 4.9 — chronyc tracking documentation. System time, last offset and root dispersion describe different quantities. The documented clock-accuracy bound assumes the primary time source is correct. Reviewed 2026-11-13.
- W3C — High Resolution Time, Working Draft 6 November 2026. Separates monotonic time used for elapsed measurements from adjustable wall-clock time; a browser elapsed clock is not automatically another host’s UTC clock. This is a Working Draft. Reviewed 2026-11-13.
- Leslie Lamport — Time, Clocks, and the Ordering of Events in a Distributed System. Defines a partial happened-before ordering from process and message relationships; it does not make every pair causally comparable. Reviewed 2026-11-13.
Turn the finding into a decision
Take one unresolved pair to the operator responsible for the relevant clock or capture point. Ask for the exact field definition, the clock-reference convention and contemporaneous bound evidence. Preserve the original records privately, then export the smaller DN comparison for review. If the records themselves do not link to the same action, complete the Decision Evidence Map first.
Related DN research
Disclosure: Analysis and instrument results are editorial. Where labelled affiliate links appear, DN may receive compensation when you sign up or buy through them. Commercial relationships do not determine findings. No tested integration or guaranteed outcome is implied.
