Session filters in server time during the week London and New York are four hours apart

[Fairman]

Session filters in server time during the week London and New York are four hours apart

This week is a good reminder that hardcoding session times in server time breaks twice a year.

Many brokers run their servers on GMT+2 in winter and GMT+3 in summer, switching on the US dates so that the daily candle closes at 17:00 New York. The UK changes on different dates. So:

In normal summer: London 08:00 BST is 07:00 GMT, which is 10:00 server.
In normal winter: London 08:00 GMT is 10:00 server.
In the gap week, from the UK change on 25 October to the US change on 1 November: London 08:00 GMT is 11:00 server, because the server is still on GMT+3.

An EA with a filter that says trade from 10:00 to 13:00 server time will start an hour before London opens this week.

The fix is to convert everything to GMT inside the EA. TimeGMT() in MQL5 returns the computer's GMT time, and TimeTradeServer() returns the server time. The difference between them is the server offset, which you can compute at runtime instead of hardcoding it. Then apply London's own DST rules, last Sunday of March to last Sunday of October, to get London local time.

One catch: TimeGMT depends on the clock of the machine running the terminal. On a VPS with a wrong clock it'll be wrong. I log the computed offset every hour and raise an alert if it changes by anything other than a whole hour.

[Fairman]

In the tester, TimeGMT() doesn't give real GMT, because the tester simulates time from the server's history. So any GMT conversion that relies on it won't work in backtests. The common workaround is to pass the broker's DST rule in as an input, for example GMT+2 with US DST switching, and compute the offset from the bar time itself. It's a bit more code, but it means the backtest and live trading use the same session logic. One way is to store the GMT offset per week in a small table for the years you test, which is easy to generate in Python.

[Fairman]

Another approach is to define sessions by the broker's daily candle instead of by clock time. If the server is on New York close time, the daily candle starts at 17:00 New York all year. You can then express London as an offset from New York time. That only works if London and New York keep the same gap, which is exactly what fails in these weeks. So it still needs the special case, but it's less fiddly than full GMT conversion. It also avoids needing the machine's clock to be right.

[Fairman]

Testing the logic is easy to do with a small script. Loop over every hour from January to December, compute what your EA thinks London time is, and compare with a known table. If the March and October gap weeks show the right one-hour shifts, the logic is correct. I'd run that test whenever the broker announces a server time change, since a few have moved from GMT to GMT+2 over the years. Run it on a few years, since some brokers changed their offset rules once. If your test history covers the change, the offsets will be wrong for one part of the data and right for the other.

[Fairman]

Python bots have the same issue. Using zoneinfo with Europe/London and America/New_York handles the rules properly, and you can convert broker timestamps from a known zone. The mistake to avoid is treating broker times as UTC or as London time without checking. MetaTrader5's Python package returns bar times in server time as seconds, which look like UTC timestamps but aren't. Converting them as if they were is a very common bug. Converting with the right zone once, at load time, and then working only in UTC removes a whole class of bugs from the rest of the code.

[FXS HongKong Scalper]

Good reminder. A safer way is to define sessions in the local time of each market and convert them to server time using a time zone library or a fixed table of change dates. In MQL5 there is no built in time zone support, so many traders use a small table of the DST dates for the next few years. It is also worth testing the filter on the gap weeks in the past, to make sure the EA traded the right hours. Asian sessions are easier, since Tokyo and Hong Kong do not change clocks.

[Shadow Trader]

Daylight saving changes happen on different dates in the United States and Europe. The US switches in mid-March and early November. Europe switches in late March and late October. For a few weeks each spring and autumn, the time gap between New York and London is one hour different from usual.

That sounds trivial, and it wrecks session-based logic. The London open comes an hour earlier relative to the New York open than usual. The overlap becomes shorter or longer. Data releases that hit at 8:30 New York land at a different time relative to European close.

Scalpers who run strategies by fixed server time find that "the first hour of London" has shifted. The same rule applied at the same clock time suddenly catches a different part of the session, and results change without any change in the market.

A subtle one is the broker's own server time. Some switch with the US, others with Europe, and some do not switch at all.

Checking the strategy's time filters twice a year, and then again in the odd weeks in between, avoids a lot of confusing underperformance.

How long did it take to notice after the last clock change threw a time-based setup off?