Daylight saving mismatches move your session windows twice a year
Posted: Sat Oct 31, 2026 7:52 am
Currency markets follow local clocks. The US and Europe change their clocks on different dates, so for a few weeks in spring and autumn the gap between London and New York is not the usual five hours. London open, the New York open and the 5pm rollover can all land an hour away from where a time filter assumes them.
The consequences are concrete. A rule such as "no trades 16:55 to 17:25 server time" can start protecting the wrong half hour, so the spread spike now sits inside the allowed window. A London open filter set to 08:00 can fire an hour late or an hour into the Asian handoff. Brokers also differ, because many servers keep a fixed offset that follows New York time, so the server clock itself may jump.
Practical checks:
- Know whether the platform's server time follows New York daylight saving
- Anchor time filters to UTC and convert, or to the real market event, instead of a raw server hour
- Look at the spread log during the transition weeks to confirm where the spike actually lands
Backtests are exposed too. Test data with a fixed offset can misplace sessions for a third of the year if the history was built on a different rule.
Has a daylight saving change ever made a time filter misfire on your setup, and how did you spot it?
The consequences are concrete. A rule such as "no trades 16:55 to 17:25 server time" can start protecting the wrong half hour, so the spread spike now sits inside the allowed window. A London open filter set to 08:00 can fire an hour late or an hour into the Asian handoff. Brokers also differ, because many servers keep a fixed offset that follows New York time, so the server clock itself may jump.
Practical checks:
- Know whether the platform's server time follows New York daylight saving
- Anchor time filters to UTC and convert, or to the real market event, instead of a raw server hour
- Look at the spread log during the transition weeks to confirm where the spike actually lands
Backtests are exposed too. Test data with a fixed offset can misplace sessions for a third of the year if the history was built on a different rule.
Has a daylight saving change ever made a time filter misfire on your setup, and how did you spot it?