Resampling edges: which bar does a tick belong to?
Posted: Fri Oct 30, 2026 2:12 pm
Resampling edges: which bar does a tick belong to?
Turning ticks into one-minute bars looks trivial. A tick at exactly 10:05:00.000 belongs to the bar starting at 10:05, but different tools disagree.
Some libraries put the boundary tick in the earlier bar, labeling bars by their end time. Others put it in the new bar, labeling by start time. The convention changes where highs and lows fall, and shifts the whole series by one bar relative to another source.
The effect shows up when comparing a self-built chart with a platform's chart. Small differences in highs and lows appear, and signals fire on different bars.
For strategies sensitive to bar boundaries, the mismatch matters. An entry rule based on "the close of the 10:05 bar" refers to different prices under different conventions.
The solution is to define the rule explicitly, label the convention in the code, and test it against a known bar. Take one bar from the platform and check the code reproduces its open, high, low, and close exactly.
It sounds fussy. But a one-bar offset can turn a good backtest into a poor live result, and it's among the more common hidden errors.
Does the self-built bar data match the platform's bars exactly, and has that been verified?
Turning ticks into one-minute bars looks trivial. A tick at exactly 10:05:00.000 belongs to the bar starting at 10:05, but different tools disagree.
Some libraries put the boundary tick in the earlier bar, labeling bars by their end time. Others put it in the new bar, labeling by start time. The convention changes where highs and lows fall, and shifts the whole series by one bar relative to another source.
The effect shows up when comparing a self-built chart with a platform's chart. Small differences in highs and lows appear, and signals fire on different bars.
For strategies sensitive to bar boundaries, the mismatch matters. An entry rule based on "the close of the 10:05 bar" refers to different prices under different conventions.
The solution is to define the rule explicitly, label the convention in the code, and test it against a known bar. Take one bar from the platform and check the code reproduces its open, high, low, and close exactly.
It sounds fussy. But a one-bar offset can turn a good backtest into a poor live result, and it's among the more common hidden errors.
Does the self-built bar data match the platform's bars exactly, and has that been verified?