Tick files are stamped in UTC, in a GMT+2 or GMT+3 server time that follows US daylight saving, or in something else entirely. A session filter like 07:00 to 10:00 only means something if the data and the rules agree on the clock. The US and Europe change their clocks on different dates, so for two or three weeks each spring and autumn the offset between a data source and a broker server can differ by an hour.
For a scalper built around the London open, that hour is the difference between trading the opening burst and trading the dead stretch before it. The test results for those weeks quietly belong to a different strategy, and nothing in the report warns about it.
A simple diagnostic: compute the average range for each hour of the day, by month. The hour with the largest range should hold steady relative to the real session open. If the peak hour steps by one at the clock-change weeks, a shift is hiding in the data.
The robust habit is to store everything in UTC and convert explicitly in one place, rather than trusting each file's stamps. Also compare a known event, like a major release, against its timestamp.
Has a DST shift ever silently broken a session filter for you, and how did you spot it?
Timezone and DST mismatches in tick data
-
Amanhasnoname
- Posts: 1506
- Joined: Fri Oct 30, 2026 9:45 am