The daylight saving week that broke every session filter

[Fairman]

The daylight saving week that broke every session filter

Most MT4 and MT5 brokers run server time at GMT+2 in winter and GMT+3 in summer, so the daily candle closes around 5pm New York. Tidy, until the US and Europe change their clocks on different weekends.

For a couple of weeks each spring and autumn, the gap between server time and New York time shifts by an hour. Anything hardcoded to server hours suddenly sits an hour wrong.

A scalper running an Asian range indicator notices ranges starting at odd times. A London open breakout filter fires an hour early. An expert advisor with fixed session hours trades the dead zone thinking it is the open, and nothing in the code changed, so nothing looks broken.

The losses build slowly. Spread is wider than expected, volume is thinner, and the strategy that worked for months suddenly looks off. Only a trade-by-trade timestamp review reveals that the entries clustered in the wrong hour.

The fix is dull and permanent. Derive sessions from UTC or a defined exchange clock, never from raw server time, and mark the clock-change weeks on the calendar.

Once a year it is worth checking whether hardcoded hours in any tool still line up with the real sessions.

A simple audit takes an evening. List every rule, indicator, or script that refers to a clock time. Next to each one, write whether the time is server time, local time, or UTC. Then check what happens to it during the two awkward weeks. Anything that fails the check gets rewritten to reference UTC or a named exchange session.

Alerts are worth including. A reminder that fires at the wrong hour can cause as much damage as a script that trades at the wrong hour, since it pulls attention to the screen at a time the market is not doing anything.

A last detail is the broker's own calendar. Some brokers change their server clock on the same day as the US, others on the same day as Europe, and a few never change it at all. The only way to know is checking the timestamps of the first and last bar of a day before and after the change.

Has a clock change ever quietly shifted a strategy's behaviour for days before anyone noticed?

[PTScalper]

The daylight saving week that broke every session filter

Most MT4 and MT5 brokers run server time at GMT+2 in winter and GMT+3 in summer, so the daily candle closes around 5pm New York. Tidy, until the US and Europe change their clocks on different weekends.

For a couple of weeks each spring and autumn, the gap between server time and New York time shifts by an hour. Anything hardcoded to server hours suddenly sits an hour wrong.

A scalper running an Asian range indicator notices ranges starting at odd times. A London open breakout filter fires an hour early. An expert advisor with fixed session hours trades the dead zone thinking it is the open, and nothing in the code changed, so nothing looks broken.

The losses build slowly. Spread is wider than expected, volume is thinner, and the strategy that worked for months suddenly looks off. Only a trade-by-trade timestamp review reveals that the entries clustered in the wrong hour.

The fix is dull and permanent. Derive sessions from UTC or a defined exchange clock, never from raw server time, and mark the clock-change weeks on the calendar.

Once a year it is worth checking whether hardcoded hours in any tool still line up with the real sessions.

A simple audit takes an evening. List every rule, indicator, or script that refers to a clock time. Next to each one, write whether the time is server time, local time, or UTC. Then check what happens to it during the two awkward weeks. Anything that fails the check gets rewritten to reference UTC or a named exchange session.

Alerts are worth including. A reminder that fires at the wrong hour can cause as much damage as a script that trades at the wrong hour, since it pulls attention to the screen at a time the market is not doing anything.

A last detail is the broker's own calendar. Some brokers change their server clock on the same day as the US, others on the same day as Europe, and a few never change it at all. The only way to know is checking the timestamps of the first and last bar of a day before and after the change.

Has a clock change ever quietly shifted a strategy's behaviour for days before anyone noticed?

Hi Fairman,

how are you?

That is a spot-on description of one of algorithmic trading's most insidious silent killers.

Every automated trader who relies on session-based logic has been burned by this at least once. Because the platform executes without throwing an error, the logs look pristine. The orders go out, the fills happen, and everything feels operational—meanwhile, your London breakout strategy is firing right into the pre-dawn liquidity vacuum, or your Asian range filter is gobbling up spread during the volatile overlap.

[PTScalper]

Why This Trap Is So Hard to Catch

The Mismatched Transition Window: The United States and Europe do not change their clocks on the same weekends. This creates a multi-week buffer in both spring and autumn where the time delta between New York, London, and your broker's server shifts by a full hour.

Broker Fragmentation: There is no universal standard for MetaTrader server times. Some brokers shift with the US, some with the UK/EU, and a significant chunk keep their servers pinned to GMT+2 (or GMT+3) year-round to avoid disrupting historical chart continuity. If your broker doesn't match the exchange you're trying to trade, your hardcoded hour inputs instantly become obsolete twice a year.

The Backtest Illusion: Most traders backtest over multi-year datasets where historical tick data either absorbed DST shifts or normalized them to UTC. When the strategy hits live forward-testing during an awkward clock-change week, reality diverges from the backtest model without any warning light flashing on your terminal.

[PTScalper]

The Fix in Practice

Your prescription—moving away from raw server time and standardizing everything to UTC or a direct exchange clock—is the industry-standard cure. Modern Expert Advisors (EAs) and scripts increasingly use time-zone conversion functions or time-stamping libraries that query UTC directly, letting the code calculate session boundaries dynamically rather than relying on static server hours like if (Hour() == 8).

[PTScalper]

To achieve this, professional developers use several battle-tested coding practices to automatically account for broker server time vs. UTC.

1. Never Hardcode Broker Offsets

Many traders calculate UTC offset by hardcoding +2 or +3 into their inputs. Because brokers change offsets on varying weekends (or sometimes don't change them at all), hardcoded numbers break during transition weeks.

Instead, calculate the offset dynamically or use code that identifies exact session bounds based on absolute UTC time.

[PTScalper]

2. Leverage TimeGMT() for Universal Baseline Time

MQL4 and MQL5 provide TimeGMT(), which returns the current Greenwich Mean Time (effectively UTC).

Important Caveat: TimeGMT() relies on the local computer's operating system clock and its internal DST rules. If your MetaTrader terminal is hosted on a Virtual Private Server (VPS), ensure the Windows/Linux timezone and automatic DST updates are correctly configured.

You can instantly find your broker's current live server offset in seconds by comparing TimeCurrent() (broker time) against TimeGMT() (UTC):

Code: Select all

// MQL5 Example: Dynamic Offset Calculation
datetime serverTime = TimeCurrent();
datetime utcTime    = TimeGMT();

// Difference in seconds between broker server and UTC
int brokerOffsetSeconds = (int)(serverTime - utcTime); 
int brokerOffsetHours   = brokerOffsetSeconds / 3600;

[PTScalper]

3. Build a DST-Aware Helper Function for Sessions

Rather than checking server hours, write a function that translates current server time into UTC time first, and then evaluates whether that UTC timestamp falls inside your target session.

For example, if you want a strategy to trigger during the London Open (which is always anchored to London local time, shifting between GMT+0 and GMT+1), base the logic on UTC:

Code: Select all

bool IsLondonOpenUTC(datetime currentTime) {
   // Convert broker time to UTC
   MqlDateTime dt;
   TimeToStruct(currentTime, dt);
   
   // Approximate or algorithmically determine if UK is in DST (Last Sunday of March to Last Sunday of October)
   // Better yet, evaluate hours based on strict UTC bounds:
   // London Open is 08:00 Local London time. 
   // In winter (UTC+0), that is 08:00 UTC. In summer (UTC+1), that is 07:00 UTC.
   
   int utcHour = dt.hour; // Assuming your base check uses a UTC-normalized time variable
   
   // Example logic framework checking UTC hour ranges
   // (A complete implementation uses an algorithm to check exact EU/US DST Sunday transition dates)
   return (utcHour >= 7 && utcHour < 16); 
}

[PTScalper]

4. Hardcode DST Transition Rule Functions (The Calendar Logic)

To make an Expert Advisor fully immune to transition-week discrepancies, embed standard algorithms that calculate the exact US and European daylight saving switch dates for any given year.

In the US, DST begins on the second Sunday in March and ends on the first Sunday in November. In Europe, it begins on the last Sunday in March and ends on the last Sunday in October.

You can program a utility function to check if a specific datetime falls inside the "awkward gap" weeks:

Code: Select all

bool IsUSdst(datetime time) {
   MqlDateTime dt;
   TimeToStruct(time, dt);
   
   // Logic to find the second Sunday of March and first Sunday of November
   // Returns true if date is within US DST range
   // ... [DST Date Math Implementation] ...
   return true; 
}

[PTScalper]

5. Account for Strategy Tester Limitations

Be careful when backtesting. Functions like TimeGMT() or local computer dependencies can behave unpredictably or return zero/invalid data inside the MT4/MT5 Strategy Tester depending on whether you are using tick data and how historical GMT shifts are modeled.

Best Practice for Backtesting: Ensure your custom time-translation functions accept a datetime parameter and rely entirely on algorithmic math derived from that timestamp rather than live system calls (TimeGMT()), ensuring identical behavior in both live execution and historical backtests.

[Fairman]

Doing alright, thanks, just recovering from a messy week of clock changes myself. And yes, the "logs look pristine" part is exactly what makes it nasty. Nothing errors, the strategy just slowly gets worse, and you blame the market first.

What caught me once was the gap between the two change dates. The US moved on a Sunday and Europe a few weeks later, so my broker's server offset was out of line with London for stretches. My London breakout window was meant to start at 08:00 UTC. For three weeks it was effectively starting at 07:00, which is a thin hour on EURGBP where the spread sat near 1.8 pips instead of 0.9. On 0.4 lots with a 6 pip stop, that extra spread alone eats roughly 15 percent of the risk before price moves.

I now store the session start in UTC and convert with a lookup of the broker's offset by date. Do you read the offset from the terminal's time functions, or keep a manual table? And have you seen brokers that never change server time at all?