Event Time vs Ingest Time

A trade prints on an exchange at 10:00:00.000. It travels across a network, sits briefly in a queue, and your system's ingestion process finally writes it to disk at 10:00:00.180 — a hundred and eighty milliseconds later. Those are two different timestamps describing the same event, and a system that only keeps one of them has thrown away information it will eventually need. Event time is when the thing actually happened in the world; ingest time (also called processing time) is when your system found out about it. They are always at least slightly different, and in a backtest that difference is the entire ballgame.

The danger is subtle: if a backtest uses event time to decide when a signal "could" have been acted on, it implicitly assumes the strategy knew about the event the instant it happened — with zero network delay, zero processing delay, zero queue time. That's not a real trading system; it's a system with a time machine. Every real pipeline has some latency between an event occurring and a decision being made on it, and if that latency isn't modeled, the backtest is quietly using information before it was actually available. This is a specific, easy-to-miss form of lookahead bias, distinct from the more commonly discussed accounting-restatement kind.

The same distinction matters for out-of-order data, which every real market data feed produces at some rate. A message can be ingested at 10:00:01 that carries an event timestamp of 9:59:58, because it was delayed, retransmitted, or arrived out of sequence relative to a neighboring feed. A pipeline that sorts strictly by ingest time will process it in the wrong logical order; a pipeline that sorts by event time will place it correctly but has to decide how long to wait before declaring a time window "closed," since a late arrival might still be coming.

Worked example: a backtest with hidden foresight

Suppose a signal reacts to a large trade print. The backtest engine is written to trigger the strategy "at the timestamp on the trade record" — which is the exchange's event time, 10:00:00.000. In live trading, the same trade wouldn't reach the strategy until ingest time, roughly 10:00:00.180 later, after network transit and parsing. If the backtest lets the strategy trade instantly at the event timestamp, it's effectively giving the backtested strategy an 180-millisecond head start over every session, every day, compounding into a return edge that a live version of the same strategy could never actually achieve. The fix is to trigger decisions off a realistic ingest-time (or ingest-time-plus-latency) timestamp, not the event timestamp on the record itself.

What this means in practice

Store both timestamps on every record where possible — exchange event time for correctness of sequencing and analysis, ingest time for realistic simulation of what a live system could have known and when. Backtests should drive decision logic off a timestamp that reflects when the information was actually available to the strategy, including a realistic latency estimate, not the timestamp the event itself carries. Skipping this distinction is one of the most common ways a backtest quietly overstates performance without any single line of code looking obviously wrong.