Event Time vs Receipt Time in Agentic Trading Data

For an autonomous trading agent, timestamp semantics determine which market events enter its state snapshot. We use the following illustrative fixture to specify that information boundary before interpreting a replay.

A timestamp is only useful when its meaning is explicit. A market event can have a venue timestamp, a local receipt timestamp, and a later database write timestamp. Treating these as interchangeable makes a replay answer the wrong question: what eventually appeared in storage rather than what was available to the consumer.

A late event changes the reconstruction

Consider an illustrative feed with clocks assumed synchronized for this example. A trade has event time 12:00:00.100, local receipt time 12:00:00.420, and storage time 12:00:00.500. A decision starts at 12:00:00.300. The trade occurred before the decision and arrived afterward. A reconstruction filtered only by event time would incorrectly include it.

Keep event_time, received_at, and stored_at separately. Add the original timestamp string and its unit if the source uses an integer epoch. Those fields support different questions. Event time orders market activity. Receipt time reconstructs local information availability. Storage time diagnoses ingestion delay. A database insertion timestamp cannot recover receipt time after the fact.

Normalize representation without changing meaning

Use a documented UTC representation for comparison while retaining the original value. Record whether the source supplies seconds, milliseconds, microseconds, or nanoseconds. A value interpreted in the wrong unit can remain numerically valid while pointing to an impossible date. Reject timestamps outside a plausible collection window instead of silently coercing them.

Database behavior also matters. PostgreSQL's time documentation distinguishes transaction-start timestamps from wall-clock timestamps and describes timezone-dependent comparison behavior. Choose the function according to the column's intended meaning. Capture network receipt time independently of transaction time.

A reusable ingestion contract

For each feed, write down the source field, documented meaning, precision, timezone, and local capture point. Specify whether timestamps may arrive out of order. Include a sequence identifier where available to preserve ordering information for equal timestamps. Preserve duplicates until you can identify them using the feed's rules.

Create a small fixture containing the late trade above, a duplicate event, two events with equal timestamps, and a malformed epoch. The availability query should exclude the late trade from the earlier decision. It should preserve equal-time events and report the malformed value. These checks establish the fixture contract; production clock accuracy requires separate measurement.

What this cannot prove

Receipt minus event time combines network delay, provider processing, and clock differences. Interpret it as an apparent delivery difference unless clock accuracy is established. If clock synchronization is uncertain, label the difference accordingly. For historical datasets lacking receipt times, state that consumer availability is unknown and run sensitivity analyses rather than inventing precise arrival times. Good timestamp engineering makes this uncertainty visible. It cannot remove information the collector never recorded.

Place this check in the agent loop

Our state and memory framework explains how this input contract fits a persistent trading agent. Use the harness-transfer test design to distinguish a data-adapter change from a change in model behavior.