Order Timestamp Errors: Check Clock, Units and Request Time
Distinguish request time, server time and event time when reviewing a timestamp error. Record the documented units and request-age rule without widening it by guesswork.
Separate request time, execution time and collection time
A clock display can look reasonable while a recorded request timestamp uses a different unit or meaning. Request creation time, venue event time and local observation time describe different points in a timeline. Identify the field named in the saved error first. Then record which venue and product documented it, rather than treating every timestamp in the record as interchangeable.
Read the documented timestamp unit
A time value needs its unit and format. A long integer could represent seconds, milliseconds or microseconds, while a formatted timestamp can include an explicit UTC offset. Preserve the original text along with the documented interpretation. Changing a string into a convenient display before identifying its meaning can hide the very mismatch needed to explain an error in a saved record.
Compare a saved client observation with a server-time reference
A server-time observation provides context for comparing a client clock, but its capture time also matters. Keep both observations and the moment they were collected. A clock sample obtained much later cannot establish the exact difference when the request was handled. Use the venue's documented server-time field as a reference rather than replacing missing evidence with the current time on your screen.
Distinguish age allowance from response timeout
A request-age allowance describes whether a request is timely under a specific contract. It is not the time you should expect to wait for a response. Binance's recvWindow and OKX's authentication timestamp rules must retain their separate formats and conditions. The example below examines one age condition only; it does not establish successful authentication, acceptance by other checks or actual execution.
Use the clock-evidence checklist
The CSV organizes field name, client and server observations, unit, error label and reference. The TXT asks the same questions without an application connection. Keep unresolved meanings visible and retain the original error text. This is a review of existing evidence, without signing requests, widening timing settings, placing orders or instructing you to change a live account's configuration.
Documented venue distinctions
These statements apply to the named provider and documented product. They do not imply identical rules elsewhere.
- Binance signed-request timing checks use timestamp and recvWindow; recvWindow is a request-age allowance rather than a response timeout. Official reference.
- Binance server-time documentation identifies serverTime for clock comparison. Official reference.
- OKX authentication and system-time responses use different documented representations; its time rule is venue-specific. Official reference.
Hypothetical case
Hypothetical Binance request age: 1200 milliseconds with a 5000-millisecond recvWindow passes the initial age condition; an age of 6000 does not. This example checks only age, without implying successful authentication or execution.
Six questions for your record
- Which field and venue produced the error?
- Is the value seconds, milliseconds, microseconds or a timestamp string?
- What server-time observation was retained?
- When was the client observation taken?
- What exact request-age rule applies?
- Is the result still unknown after other checks?
Keep your own record
The CSV contains column headings only. The TXT contains the review questions and blank note spaces. Keep original evidence separately, preserve identifiers as text and leave missing facts unknown. Neither file sends data or performs an account check.