Why milliseconds in your tick timestamps decide whether a backtest is believable
Posted: Sat Oct 31, 2026 7:15 pm
Timestamp resolution is one of those details that looks pointless until a result flips because of it. A few places where milliseconds (or the lack of them) change the picture:
- Ordering of events inside one second. If ticks are stamped to the second, several quotes share a time, and the tester has to decide which came first. Two quotes with opposite moves can swap places.
- News reactions. The first reaction to a release often lasts a fraction of a second. Second-level stamps compress that into a single blob and hide the spike that would have hit a stop.
- Latency studies. Measuring how long an order takes from signal to fill needs resolution finer than the delay being measured. Second-level data cannot show a 150 ms lag.
- Matching two data sources. Joining a broker log to a third-party feed by timestamp falls apart when one side rounds and the other does not, and clocks may also be offset by a few hundred milliseconds.
- Dedupe errors. Identical timestamps can make a clean tick look like a duplicate and get dropped.
For slower methods none of this matters. For anything holding positions for seconds, it does.
What resolution does your tick data have, and has it ever changed how you read a fast move?
- Ordering of events inside one second. If ticks are stamped to the second, several quotes share a time, and the tester has to decide which came first. Two quotes with opposite moves can swap places.
- News reactions. The first reaction to a release often lasts a fraction of a second. Second-level stamps compress that into a single blob and hide the spike that would have hit a stop.
- Latency studies. Measuring how long an order takes from signal to fill needs resolution finer than the delay being measured. Second-level data cannot show a 150 ms lag.
- Matching two data sources. Joining a broker log to a third-party feed by timestamp falls apart when one side rounds and the other does not, and clocks may also be offset by a few hundred milliseconds.
- Dedupe errors. Identical timestamps can make a clean tick look like a duplicate and get dropped.
For slower methods none of this matters. For anything holding positions for seconds, it does.
What resolution does your tick data have, and has it ever changed how you read a fast move?