Why Your EA Session Filter Breaks Every DST Change

Your EA was filtering trades to the London session perfectly — until the clocks changed last week. Now it’s opening positions an hour early, and it will keep doing that until October, when it will shift again in the opposite direction. Hardcoded timezone offsets, ignored DST transitions, and misunderstood server time break session-filtered EAs exactly twice a year — and most traders only discover the problem after unexpected trades have already executed.

The EA didn’t break. It was always broken. Hardcoded timezone logic is only wrong twice a year, which makes it the most dangerous kind of bug: one that works 363 days and fails on the two days that matter.

The Symptom: Trades Outside Your Session Window

Every March and October, I see the same pattern in client requests: “My EA traded outside allowed hours.” The trader is running a session filter — London only, or New York only — and suddenly trades appear an hour early or an hour late.

The EA didn’t malfunction. It followed the time logic it was given, and that logic was wrong.

A typical case: an EA configured for the London session, 08:00 to 16:00 GMT. Last Monday it started opening positions at 07:00 GMT. The trader assumed a broker issue. The actual cause was a hardcoded `+2` offset in the time calculation that was correct during winter (when the broker’s server ran GMT+2) and wrong the moment the clocks shifted to summer time (GMT+3). That single digit — `2` instead of `3` — moved the entire trading window by one hour.

This is not rare. In my experience across 13 years of EA development, timezone bugs rank in the top 5 most common production failures.

Why TimeCurrent() Isn’t What You Think It Is

`TimeCurrent()` returns the broker’s server time. Not GMT. Not your local time. Not UTC. The broker’s server clock — and its relationship to GMT depends entirely on which broker you’re using.

This distinction matters because brokers don’t all run on the same timezone:

The same EA running on both brokers, with the same hardcoded offset, produces different session windows. On Broker A, those windows shift by one hour twice a year. On Broker B, they never shift.

If your EA calculates GMT by subtracting a fixed number from `TimeCurrent()`, it silently produces the wrong time every time the broker’s DST status changes. No error message. No warning. The EA just starts trading at the wrong hours.

Most traders configure their EA once, verify it works for a few days, and move on. The offset was correct at the time. Six months later, the clocks change, and the EA is off by an hour in a direction nobody anticipated.

The Three Ways EAs Get Time Wrong

In my client work, nearly every session-filter bug falls into one of three categories.

1. Hardcoded GMT Offset

The most common failure. The EA converts server time to GMT using a fixed constant:

datetime gmtTime = TimeCurrent() - 2 * 3600;

This line is correct only when the broker server is running GMT+2. The moment DST shifts the server to GMT+3, this calculation is off by one hour. The EA opens and closes trades at the wrong time, and will continue doing so for six months until the next DST transition silently “fixes” it — only to break again in the opposite direction.

I’ve seen this pattern in EAs from freelancers, commercial products, and AI-generated code. The fix is straightforward, but only if you know the problem exists.

2. Using TimeLocal() for Server-Side Decisions

`TimeLocal()` returns the clock time of the machine running MetaTrader — your PC or VPS. If your VPS is in Amsterdam and your broker’s server is in New York, `TimeLocal()` and `TimeCurrent()` return different times. Any session logic based on `TimeLocal()` is wrong from the first tick.

This bug is especially insidious because it can appear to work during testing. If you test on your local machine and your local timezone happens to match the broker’s server timezone, the session filter behaves correctly. Deploy the same EA to a VPS in a different timezone, and the session window shifts by however many hours separate the two clocks.

I’ve debugged three separate client EAs in the past year where this was the root cause. In each case, the EA “worked perfectly on my laptop” and “traded at random hours on my VPS.”

3. Sunday and Monday Bar Edge Cases

Not all brokers open at the same time. Some brokers start their trading week on Sunday evening (server time). Others start on Monday. An EA that checks “is it Monday?” at a hardcoded hour can miss the entire first day of the week on one broker, or fire trades on a Sunday that should have waited until Monday on another.

This creates silent differences: the same EA, the same settings, different results depending on when the broker’s weekly candle starts. Backtesting won’t catch it unless you specifically compare results across the Sunday-Monday boundary.

What Reliable Time Handling Looks Like

The production-safe approach avoids hardcoded offsets entirely. Instead, it uses the broker’s own data to derive the current GMT offset dynamically.

The forex trading day resets at the New York session close — 5:00 PM Eastern Time — and most brokers align their daily bar to open at 00:00 server time on that reset. For a broker running GMT+2 in winter, the daily bar opens at 00:00 server time, which corresponds to 22:00 GMT. When that same broker shifts to GMT+3 in summer, the daily bar still opens at 00:00 server time, but now that corresponds to 21:00 GMT.

The dynamic offset technique exploits this: the EA reads the broker’s daily bar open timestamp and compares it against the known New York close time in GMT (which follows the US DST schedule). If the daily bar opened at 00:00 server time and the NY close was at 22:00 GMT that day, the broker is running GMT+2. If next week the NY close shifts to 21:00 GMT (US summer time) but the daily bar still opens at 00:00 server time with the same offset, the broker hasn’t changed. When the broker’s own DST kicks in and the relationship shifts, the EA detects it automatically. No code change. No manual input.

MQL5 introduced `TimeGMTOffset()`, which looks like a solution but solves a different problem. It returns the offset between GMT and the terminal machine’s local clock — not the broker server’s clock. If your VPS timezone doesn’t match the broker, `TimeGMTOffset()` gives you the wrong value for server-to-GMT conversion.

At barmenteros FX, this is the kind of time handling architecture we build into production EAs. It’s invisible when it works — no inputs to configure, no offsets to update. But it’s the difference between an EA that survives every DST transition quietly and one that surprises you twice a year.

How to Tell If Your EA Has This Problem

Three checks you can run right now:

1. Search the source code or inputs for hardcoded offsets. Look for constants like `+2`, `+3`, `-5`, or any `* 3600` multiplication in time-related logic. If you find a fixed number being added to or subtracted from `TimeCurrent()`, your EA is DST-vulnerable.

2. Compare session timing after a DST change. If your EA logs its session boundaries (e.g., “Session active: 08:00 to 16:00”), check those logs the week after a DST shift. If the logged times haven’t changed but your intended GMT window has moved by one hour, the EA is using a stale offset.

3. Backtest across a DST boundary. Run a backtest that spans the last DST transition — late March 2026 or late October 2025. Check the trade log for entries appearing one hour earlier or later than expected around those dates. If the shift appears, the EA has a time handling defect.

If any of these checks reveals a problem, the fix depends on your EA’s architecture. A simple offset swap in the inputs buys you six months until the next DST shift. A proper solution — dynamic offset detection from broker data — fixes it permanently.