Session-range EAs and the 25 Oct to 1 Nov DST gap on GMT+2/+3 servers

New comment

Most brokers on GMT+2/+3 server time follow the US DST schedule so the daily close stays at 17:00 New York. Europe ends DST on 25 October and the US on 1 November, so for that week London opens one hour earlier in server time than usual. The same thing happens in March in reverse.


For EAs that build an Asian range from fixed server hours and trade the London breakout, the range window and the London open are misaligned for about a week, twice a year.


How are people handling this?

1. Keep fixed server hours and accept that week

2. Work out session times from GMT (TimeTradeServer() minus TimeGMT()) plus an internal DST table

3. Skip trading during the mismatch weeks


The catch with option 2: in the Strategy Tester, TimeGMT() returns the simulated server time, so the offset logic behaves differently in backtests than live unless the offset is hard-coded by date. Has anyone found a clean way to keep this reproducible in the tester?

Tommy Wang:
How are people handling this?

Code Base

TimeGMT library for the strategy tester

amrali, 2024.02.22 01:54

Static class to fix the TimeGMT() function during testing in the strategy tester.

First a correction, because it decides which way the window has to move. On a +2/+3 server that follows New York, 08:00 London is 10:00 server time in summer and in winter. In the gap week the server is still on +3 while London is already back on GMT, so the open lands at 11:00, one hour later. March gives the same direction, not the reverse, and that gap is longer than a week, from the second Sunday of March to the last Sunday of March, so two or three weeks depending on the year.

For reproducibility I stopped asking the terminal for the offset. On such a server the offset is a function of the date, +3 while US daylight saving is active and +2 otherwise, and the switch dates follow fixed rules (US second Sunday of March and first Sunday of November, EU last Sunday of March and October). I compute them from the date itself, so the same bar gets the same session window in a backtest and live, and TimeGMT never enters the calculation. What I would check once per broker is that the server really switches with New York.

Tommy Wang: Most brokers on GMT+2/+3 server time follow the US DST schedule so the daily close stays at 17:00 New York. Europe ends DST on 25 October and the US on 1 November, so for that week London opens one hour earlier in server time than usual. The same thing happens in March in reverse. For EAs that build an Asian range from fixed server hours and trade the London breakout, the range window and the London open are misaligned for about a week, twice a year. How are people handling this? 1. Keep fixed server hours and accept that week 2. Work out session times from GMT (TimeTradeServer() minus TimeGMT()) plus an internal DST table 3. Skip trading during the mismatch weeks The catch with option 2: in the Strategy Tester, TimeGMT() returns the simulated server time, so the offset logic behaves differently in backtests than live unless the offset is hard-coded by date. Has anyone found a clean way to keep this reproducible in the tester?

Example codes for MT5 and MT4:

Code Base

V1N1 LONNY MT5

Vinicius Pereira De Oliveira, 2026.06.18 22:36

Asian Range Breakout day-trading EA. Multi-symbol, M15/M30/H1. Places pending stop orders during the London session outside the pre-London Asian range, using PSAR + MACD + Stochastic signals, with automatic London/NY DST handling, structural stops, trailing and break-even.

Code Base

V1N1 LONNY MT4

Vinicius Pereira De Oliveira, 2017.01.25 09:12

Asian Range Breakout day-trading EA. Multi-symbol, M15/M30/H1. Places pending stop orders during the London session outside the pre-London Asian range, using PSAR + MACD + Stochastic signals, with automatic London/NY DST handling, structural stops, trailing and break-even.

Yeah, that tester behaviour is documented, TimeGMT() just returns the simulated server time in a backtest, so option 2 can't rely on it there. What I'd do is compute the server offset yourself from the date: these brokers follow US DST (second Sunday of March to first Sunday of November), so it's +3 inside that window and +2 outside. UK DST is last Sunday of March to last Sunday of October, so London 08:00 in server time is 8 - ukOffset + serverOffset. Same function live and in the tester, so results stay reproducible.

Tommy Wang:

Most brokers on GMT+2/+3 server time follow the US DST schedule so the daily close stays at 17:00 New York. Europe ends DST on 25 October and the US on 1 November, so for that week London opens one hour earlier in server time than usual. The same thing happens in March in reverse.


For EAs that build an Asian range from fixed server hours and trade the London breakout, the range window and the London open are misaligned for about a week, twice a year.


How are people handling this?

1. Keep fixed server hours and accept that week

2. Work out session times from GMT (TimeTradeServer() minus TimeGMT()) plus an internal DST table

3. Skip trading during the mismatch weeks


The catch with option 2: in the Strategy Tester, TimeGMT() returns the simulated server time, so the offset logic behaves differently in backtests than live unless the offset is hard-coded by date. Has anyone found a clean way to keep this reproducible in the tester?

One thing worth adding for planning: the spring gap is longer than the autumn one. This year the autumn gap is one week (Europe 25 October, US 1 November). Next spring the US moves on 14 March 2027 and Europe on 28 March 2027, so it is two weeks. In both gaps the London open lands one hour later in server time (11:00 instead of 10:00 on a +2/+3 New York server), so option 3 costs you three weeks a year, not two.

Whichever way you compute the offset, I would check it against the broker's own history rather than trust the rule. On a New York close server the daily bar starts at the 17:00 NY close, so print your computed offset for every day from mid-March to early April and from late October to early November, and compare it with where the H1 bars actually show the London volume spike in that broker's history. If they disagree on even one day, the rule or the broker's switch date is off, and you find out in the tester instead of live.

New comment