Timestamps and the millisecond problem
Posted: Fri Oct 30, 2026 9:11 am
Timestamps and the millisecond problem
Tick data carries timestamps. Some in seconds, some in milliseconds. The resolution matters.
Second-resolution timestamps make multiple ticks within the same second indistinguishable in order. A backtest has to guess the sequence, which creates the same kind of uncertainty as bar-based data, just on a smaller scale.
Millisecond timestamps preserve the order. For scalping systems with fast entries and exits, this resolution is needed.
Another issue is the timestamp source. Is it the time the broker's server generated the tick, the time the platform received it, or the time the data provider recorded it? The differences can be tens or hundreds of milliseconds.
Comparing data from two sources can show systematic offsets. Aligning them properly is a boring job that decides whether a latency-sensitive test means anything.
A quick sanity check is to count how many ticks share an identical timestamp in the dataset. On second-resolution data, a busy minute can have dozens of ticks stamped with the same second, and the order among them is invisible. If that count is high, any tick-level conclusion drawn from the file deserves heavy scepticism.
What timestamp resolution does the tick data being used provide, and where do the timestamps come from?
Tick data carries timestamps. Some in seconds, some in milliseconds. The resolution matters.
Second-resolution timestamps make multiple ticks within the same second indistinguishable in order. A backtest has to guess the sequence, which creates the same kind of uncertainty as bar-based data, just on a smaller scale.
Millisecond timestamps preserve the order. For scalping systems with fast entries and exits, this resolution is needed.
Another issue is the timestamp source. Is it the time the broker's server generated the tick, the time the platform received it, or the time the data provider recorded it? The differences can be tens or hundreds of milliseconds.
Comparing data from two sources can show systematic offsets. Aligning them properly is a boring job that decides whether a latency-sensitive test means anything.
A quick sanity check is to count how many ticks share an identical timestamp in the dataset. On second-resolution data, a busy minute can have dozens of ticks stamped with the same second, and the order among them is invisible. If that count is high, any tick-level conclusion drawn from the file deserves heavy scepticism.
What timestamp resolution does the tick data being used provide, and where do the timestamps come from?