Twice a year, many EAs quietly trade at the wrong time. The US and Europe change clocks on different dates, and broker server time often follows New York close (GMT+2/+3), so there are weeks when everything shifts by an hour relative to each other.
Things that broke in my EAs over the years:
Session filters in server time. A "London open" filter hard-coded to 10:00 server time was wrong for two to three weeks each spring and autumn.
News times. Calendar in UTC, EA in server time, conversion done with a fixed offset.
Daily candles. The day boundary moved, so "yesterday's high" referred to a slightly different period.
Backtests. Historical data in one convention, filters in another.
My fixes:
All time logic in UTC inside the EA. Convert server time to UTC with an offset calculated from TimeTradeServer() and TimeGMT(), not hard-coded.
Session times defined in local time of the market (London, New York) and converted with proper DST rules.
A log line every Monday printing the calculated offsets, so I can check them quickly.
We're right in the mismatch period now, with Europe already on winter time and the US changing next weekend. Check your EAs this week. Has DST ever cost you a trade?
A mini case study that sounds boring and ends oddly.
Someone builds a scalping approach around the first minute after the hour. The idea is that many orders and data points cluster at round times, so the first one-minute bar of an hour tends to carry an unusual burst. Testing across two years looks promising: the first bar breaks a recent range, entries on the break show a clear edge.
Then the same logic is tested on a different broker's history, and the edge nearly vanishes. Same pair, same period, same rules. After a lot of head scratching, the cause turns up: the two servers use different time zone offsets. One shifts with daylight saving following the American schedule, the other is fixed. For part of each year, the "top of the hour" bar on one platform was actually the half past bar on the other, or the bar boundary was shifted by an hour relative to real market events.
The twist is that the original edge was real for some of the year and just wrong for the rest. In the months where the server clock lined up with actual event times, the burst was visible. In the shifted months, the strategy was trading a random bar and diluting the result.
Anything keyed to a clock time, such as session opens, fixes, release times or hourly effects, depends on knowing exactly how server time maps to real time, including what happens on the daylight saving switch dates. Candle boundaries themselves also move: an hourly or daily bar starts at a different real moment depending on the offset.
A sensible habit is to convert everything to a single reference like UTC before testing, then check a handful of known events, such as a major data release, to confirm the spike lands where it should.
How do you verify your server offset, and has a time zone shift ever made a result look better or worse than it was?
