Case study: the strategy that stopped working twice a year, and the clock was the reason
Posted: Sat Oct 31, 2026 11:31 am
A scalper builds a routine around the Tokyo open. It works through the winter, produces a decent month in March, and then in October the results quietly fall apart. Nothing in the setup has changed. The entries are the same, the filters are the same, and the broker is the same. The drawdown gets blamed on market conditions, the model gets tweaked, and by spring the tweak is stopping out good trades.
The actual cause is the calendar. Australia observes daylight saving, with clocks moving forward in early October and back in early April. Japan does not observe it at all. Meanwhile London and New York shift on their own dates, and those dates are not the same as each other, which creates a few weeks in spring and autumn where the offsets are different from the rest of the year.
The result is that a fixed server-time schedule slides against the real sessions. A routine that targeted the first hour of Sydney, meaning the stretch right after the local open, lands an hour earlier or later relative to Tokyo and relative to London's early hours. The setup was never wrong about the market. It was keyed to a clock that moved when the market did not.
The twist is that the fix is boring. Anchoring the schedule to local session time rather than to the chart's timestamp makes the problem disappear, and so does checking whether the broker server shifts on the US schedule, the European schedule, or not at all. Brokers vary on this, and the platform clock is not always what it appears to be.
It also explains why some seasonal results look strange in backtests. A test run on server time mixes two slightly different market alignments into the same bucket.
A simple audit helps: line up trade timestamps for each month against actual session opens and look for a step change at the shift dates.
Has anyone found an unexplained performance dip that turned out to be a daylight saving offset, and how did it show up in the stats?
The actual cause is the calendar. Australia observes daylight saving, with clocks moving forward in early October and back in early April. Japan does not observe it at all. Meanwhile London and New York shift on their own dates, and those dates are not the same as each other, which creates a few weeks in spring and autumn where the offsets are different from the rest of the year.
The result is that a fixed server-time schedule slides against the real sessions. A routine that targeted the first hour of Sydney, meaning the stretch right after the local open, lands an hour earlier or later relative to Tokyo and relative to London's early hours. The setup was never wrong about the market. It was keyed to a clock that moved when the market did not.
The twist is that the fix is boring. Anchoring the schedule to local session time rather than to the chart's timestamp makes the problem disappear, and so does checking whether the broker server shifts on the US schedule, the European schedule, or not at all. Brokers vary on this, and the platform clock is not always what it appears to be.
It also explains why some seasonal results look strange in backtests. A test run on server time mixes two slightly different market alignments into the same bucket.
A simple audit helps: line up trade timestamps for each month against actual session opens and look for a step change at the shift dates.
Has anyone found an unexplained performance dip that turned out to be a daylight saving offset, and how did it show up in the stats?