MT4 Timezone Tutorial: Build a DST-Aware EA in 6 Steps

How to Understand the MT4 Timezone Trap

Warning: If your Expert Advisor uses time-based filtering and you haven't accounted for forex broker server time offsets, your backtest results and live performance are almost certainly operating on different clocks.

Timezone mismatches are one of the most common reasons a session-based strategy looks clean in backtesting and then misfires in live conditions. Here's what's actually happening: your historical GMT data doesn't match the GMT+2 or GMT+3 server time your broker runs in live trading. That gap means every time-based condition in your Expert Advisor — session opens, trade windows, daily resets — triggers at the wrong moment.

This mismatch also produces what developers call the "Sunday Candle" problem. When daily candle boundaries are misaligned, MT4 generates a short, low-volume candle at the start of the week that doesn't represent any real trading session. Over 90% of MT4 brokers use GMT+2 with DST specifically to align daily candles with the New York close and eliminate this artifact — but if your EA doesn't account for that offset, indicators like RSI and Moving Averages will calculate against a distorted candle set and produce unreliable signals.

DST transitions make the problem worse. The US and Europe shift their clocks on different dates, leaving a 2–3 week window each spring and fall where the offset between your strategy's assumed time and the actual broker server time is off by a full hour. During live trading conditions, that's enough to push trades outside intended session windows entirely.

TimeCurrent() returns the current broker server time — but that's only part of what you need. Without knowing the broker's GMT offset and whether DST is currently active, you can't reliably map that timestamp to real-world session boundaries. This is why building timezone logic into your EA from the start isn't optional — it's foundational.

// What most developers write:
datetime currentTime = TimeCurrent(); // Returns broker server time — offset unknown

// What a DST-aware EA actually needs:
int gmtOffset = 2; // Must be dynamic — changes with DST transitions
datetime gmtTime = TimeCurrent() - gmtOffset * 3600; // Convert to true GMT first

Before this tutorial walks through the full build, it helps to lock down the exact terminology — broker server time, GMT offset, DST transitions, and the New York close benchmark — so every step maps to a concrete, unambiguous concept in your code.

How to Define Core Time Management Terminology

Before writing a single line of MQL4, you need a firm grip on four terms. Misunderstanding any one of them is enough to break time-based logic in your Expert Advisor — even if the rest of the code is clean. The MetaTrader 4 time zone model is deceptively simple on the surface but carries real complexity once DST shifts enter the picture.

Broker Server Time

The clock displayed in your Market Watch window, typically set to GMT+2 in Winter and GMT+3 in Summer. Every call to TimeCurrent() in MQL4 returns this value — not your local time or UTC.

GMT Offset

The fixed number of hours added to or subtracted from Greenwich Mean Time to reach your broker's server time. A broker on GMT+2 returns a TimeCurrent() value that is two hours ahead of UTC.

DST (Daylight Saving Time)

A seasonal clock adjustment — applied in March and November — that shifts the broker's GMT offset by one hour, turning GMT+2 into GMT+3 and back again. This often causes time-filter failures, as discussed in the [Broker time zone offsets, DST, and the strategy tester](https://www.mql5.com/en/forum/427917) thread.

New York Close

The 5:00 PM EST benchmark that signals the end of the trading day and the opening of a new daily candle. As noted by [BabyPips](https://www.babypips.com), Pivot Point calculations shift materially depending on whether a broker anchors the daily candle to 00:00 GMT or 00:00 GMT+2 — directly affecting how the New York Close is mapped to server time.

These four concepts interact constantly inside a running EA. Once they're clear, setting up your development environment — including verifying your broker's exact offset — becomes a structured, repeatable process rather than guesswork.

How to Prepare Your Development Environment

Before writing a single line of MQL4 GMT offset logic, confirm that your environment is solid. Skipping this step is one of the fastest ways to produce backtest results you can't trust. As noted on the MQL5 Community Forum, the most common reason for backtesting discrepancies is the failure to account for DST shifts in history data — and this issue begins with poor setup, not poor code.

What you'll need before you start:

Broker GMT offset — Summer and Winter. Log your broker's server time against UTC during both periods. Most ECN brokers run on UTC+2 in Winter and UTC+3 in Summer, but this isn't universal. Confirm with your broker directly; don't assume.
Clean History Center data. Open Tools → History Center and check your target symbol for Sunday candles or partial weekly bars. These artifacts corrupt session-timing logic during backtesting. Delete any anomalous entries before you run a single test.
MT4 Terminal Build 1420 or higher. Earlier builds have known issues with time function behavior. Go to Help → About to verify your build number. Update if needed before proceeding.
Working knowledge of MQL4 syntax and MetaEditor. You'll be writing and compiling functions directly in MetaEditor. If you're relying on AI Generated Code to fill gaps, make sure you validate every block — AI-assisted development speeds things up, but broker execution conditions will expose any logic that wasn't verified.

⚠ Data quality warning: Even one corrupt history candle in your backtest set can cause a time-based Expert Advisor to fire trades at the wrong session. Clean data isn't optional — it's a prerequisite.

With your environment confirmed, the next step is calculating the actual GMT offset your EA will use at runtime — and that requires understanding exactly how MT4 handles server time versus real-world UTC.

Step 1: Calculate the Dynamic GMT Offset

With your environment confirmed, the first real coding task in this MT4 tutorial is building a function that reliably returns the current GMT offset at runtime — not a static integer that might be outdated by next March.

The core problem is that MT4 exposes three different time references, and confusing them is where most time-based Expert Advisors break down:

TimeCurrent() — the time of the last received tick, set by your broker's server clock
TimeGMT() — true UTC time, pulled from the MetaTrader terminal's internal sync
TimeLocal() — your PC's local system clock, which reflects your own timezone and DST settings

The offset you actually need is TimeGMT() subtracted from TimeCurrent(). That delta, divided by 3600, gives you the broker's current hour shift as an integer. Do not use TimeLocal() for this calculation — it introduces your machine's timezone into server-side logic, which fails on a VPS in another region.

Here's what that offset function looks like in practice:

int GetServerGMTOffset()
  {
   datetime serverTime = TimeCurrent();
   datetime gmtTime    = TimeGMT();
   int offsetSeconds   = (int)(serverTime - gmtTime);
   int offsetHours     = offsetSeconds / 3600;
   return offsetHours;
  }

Verification step: After writing the function, call it inside OnInit() and print the result to the Experts log so you can confirm it matches your broker's stated GMT offset before any orders fire.

int OnInit()
  {
   int offset = GetServerGMTOffset();
   Print("Server GMT Offset: UTC+", offset);
   return(INIT_SUCCEEDED);
  }

Check the Experts tab in the MetaTrader terminal immediately after attaching the EA. If your broker runs on GMT+2, that's what you should see printed. A mismatch here means your session-window logic will be off by however many hours the discrepancy shows. In practice, an EA hard-coded for a specific hour without a proper offset function can trigger during low-liquidity rollover periods — a real execution risk flagged by Investopedia for time-sensitive automated strategies.

If you're generating this kind of scaffolding with an LLM, keep in mind that AI-generated MQL4 code almost never includes DST-aware offset logic out of the box — validating that function output before backtesting is non-negotiable.

With a confirmed static offset in your log, the next challenge becomes clear: that integer isn't always the same number. Twice a year, DST transitions shift it by one hour — and that's exactly what Step 2 addresses.

Step 2: Implement the DST Logic for 2026 and Beyond

To build a DST-aware EA that holds up in live trading, you need explicit date logic baked into the code — not a manual input you adjust twice a year and inevitably forget on a Sunday morning while your VPS keeps trading. This is exactly where 24/7 automated systems fail when DST handling is left to human intervention.

The approach here hard-codes the known transition dates into a boolean IsDST check. US Daylight Saving Time in 2026 begins March 8 and ends November 1, affecting every USD-paired session filter you run.

Define the transition dates as constants. Declare DST_START_MONTH=3, DST_START_DAY=8, DST_END_MONTH=11, and DST_END_DAY=1 at the top of your EA. Update these values each year — or better, calculate the second Sunday in March and first Sunday in November programmatically.

Build the IsDST boolean function. Extract the current month and day from TimeCurrent(), then evaluate against the transition window:

bool IsDST() {
   int month = TimeMonth(TimeCurrent());
   int day   = TimeDay(TimeCurrent());
   if(month > 3 && month < 11) return true;
   if(month == 3 && day >= 8)  return true;
   if(month == 11 && day < 1)  return true;
   return false;
}

Toggle the offset value. In your GMT offset function from Step 1, apply the result: int dstOffset = IsDST() ? 3 : 2;. This switches Eastern Time between UTC-4 (summer) and UTC-5 (winter) automatically.
Handle the EU/US gap weeks. The EU typically shifts clocks on the last Sunday of March — roughly two to three weeks before the US. During that window, the offset relationship between London and New York sessions shifts by one hour. Add a secondary EU DST check using the same pattern with European transition dates to cover this correctly. This gap is a [common source of session filter drift](https://www.forexfactory.com/thread/4006-how-to-change-my-timezone-in-mt4) that catches many EAs off guard.
Validate the logic against historical data. Run the MetaTrader Strategy Tester across a date range that spans at least one March and one November transition. Confirm your session open/close times shift by exactly one hour at the correct dates. Any AI Generated Code handling DST deserves this scrutiny — [generated MQL4 rarely accounts for edge cases](https://mt4programming.com/\_\_trashed-3/) like the gap week without explicit review.

Manual offset adjustment is a failure point on any VPS that runs unattended. Hard-coded, date-driven logic removes that dependency entirely. With IsDST returning reliably, the next step is putting that offset to work inside a session filter function that converts GMT times into accurate server hours.

Step 3: Build the Session Filter Function

With your GMT offset calculated and DST logic in place, the next step is applying that offset to an actual trading window. This is where understanding how to handle daylight savings in MT4 moves from theory into working code.

The core problem is straightforward: your strategy targets 08:00 GMT (London open), but your broker's server runs on GMT+2. Discrepancies between GMT backtest data and a GMT+2 live server cause execution at unintended price points, according to Investopedia. The session filter function bridges that gap.

Here's the ordered logic for building it:

Define GMT inputs. Add input int StartHourGMT = 8; and input int EndHourGMT = 17; at the top of your EA. Traders adjust these without touching core logic.
Convert GMT to server hour. Inside your filter function, apply: int serverStart = (StartHourGMT + gmtOffset) % 24;. The modulo operator handles midnight wrap-around cleanly — if your offset pushes 23:00 to hour 25, % 24 returns 1 correctly.
Repeat for the end hour. int serverEnd = (EndHourGMT + gmtOffset) % 24;
Block the rollover hour. Add a hard guard: if(Hour() == 0) return false;. The 00:00 server candle carries widened spreads at most brokers — you don't want orders firing there regardless of your session window.
Return the session state. return (Hour() >= serverStart && Hour() < serverEnd);

A quick note on validation: reviewing the logic before deployment catches offset errors that only surface at DST boundaries — don't skip that step.

bool IsInSession() {
   int serverStart = (StartHourGMT + gmtOffset) % 24;
   int serverEnd   = (EndHourGMT   + gmtOffset) % 24;
   if(Hour() == 0) return(false); // block rollover hour
   return(Hour() >= serverStart && Hour() < serverEnd);
}

With this function returning true only during valid server hours, your EA won't place trades outside the intended GMT window. In the next step, you'll run this through the MetaTrader Strategy Tester to confirm the logic holds across a real DST transition week.

Step 4: Audit and Verify Your Backtest Results

With your session filter built, don't assume it's working correctly — verify it. A DST logic error won't throw a compiler warning; it'll just place trades at the wrong time and your backtest will look plausible enough to miss it entirely.

Prerequisites before running this audit:

EA compiled with your GMT offset and DST logic from Steps 2–3
At least one full DST transition week in your backtest date range (e.g., the second Sunday of March for US DST)
Strategy Tester open in MetaTrader 4

Verification steps:

Run Every Tick mode on a date range that straddles a known DST transition. Sparse tick data will mask timing errors; Every Tick mode gives you the resolution to catch them.
Export the Journal log from the backtest and timestamp every trade entry. Cross-reference those times against the session window you defined. Any trade firing outside that window is a phantom trade.
Identify phantom trades. An EA running on 00:00 GMT will calculate different support/resistance than one on 00:00 GMT+2, leading to phantom signals — trades that exist in the backtest but have no valid trigger in real market structure.
Enable Visual Mode and watch the session box draw bar-by-bar across the DST transition. If the box shifts by one hour on the wrong date, your offset logic has a boundary condition error.
Compare pre- and post-transition trade clusters. A correctly coded EA shows consistent entry timing relative to the session open. A broken one shows a one-hour drift in the week following the clock change.

Spotting out-of-sync trades: If your trade entries cluster at a consistent time pre-transition but then shift exactly 60 minutes post-transition without a corresponding change in your DST logic, your offset calculation is applying the new GMT value one week too late — or too early.

If you're working with AI generated code as a starting point for your EA, this audit step is non-negotiable. AI Trading Systems frequently generate session logic that handles the standard offset correctly but silently fails on the DST boundary date itself.

Once your Journal log and Visual Mode audit both confirm consistent session timing across the transition week, the core logic is sound. The next step is distilling these findings into a set of time-sensitive trading rules you can apply consistently across any broker configuration.

How to Summarize Key Time-Sensitive Trading Rules

By this point in the build, you've constructed each layer of a DST-aware session filter. Before moving to final deployment, it's worth consolidating the core rules that separate a reliable time-based Expert Advisor from one that drifts off-schedule several weeks a year.

Quick-reference checklist for time-sensitive EA logic:

Use GMT as your anchor, not raw server time. Broker server time shifts with DST policies and account migrations. GMT stays fixed. Build all session window logic against a calculated GMT value, then convert to server time only at execution.
Verify your broker's DST policy before deployment. As the MQL5 community notes, because the US and Europe switch DST on different dates, fixed offsets will fail several weeks a year. US brokers typically follow EST/EDT; EU brokers follow CET/CEST. These windows don't overlap cleanly.
Audit daily candle alignment. A misaligned GMT offset shifts where the daily candle opens in MetaTrader. Indicators built on daily closes — like ATR or moving averages — will lag or misread volatility cycles if Sunday data isn't handled correctly.
Automate the offset calculation. Hardcoding a static GMT+2 or GMT+3 value is the most common source of session drift during live trading. If you're also working across multiple automation platforms, offset inconsistencies compound across instruments and timeframes.

In practice, these four rules function as a pre-deployment gate. Running through them before attaching an EA to a live account takes minutes and catches the errors that backtesting won't surface on its own. With these principles locked in, the next step is finalizing your EA and understanding when timezone complexity warrants professional-level support.

How to Finalize Your EA and Next Steps

What you built — a DST-aware session filter that dynamically adjusts trading hours based on US and EU daylight saving transitions, validated against real tick data in the MetaTrader Strategy Tester. Here's a quick checklist of what this tutorial covered:

Defined GMT offsets for your broker's server time
Built conditional DST logic for US and EU switching dates
Constructed session window checks using adjusted GMT hours
Integrated the filter into your Expert Advisor's order handling logic
Audited backtest results to confirm accurate session filtering

Where to go from here. The natural next layer is a news filter that reads from an external GMT-based economic calendar. That means pulling event timestamps, normalizing them to your broker's server time using the same offset logic you've already built, and suppressing trades within a defined window around high-impact releases. The DST framework you've constructed here is the foundation — news filtering is an extension of it.

When to bring in professional help. Multi-broker synchronization is where timezone logic gets genuinely complex. Offset values vary by broker, some servers don't follow standard DST schedules, and a filter working on one account can misfire on another. If you're deploying across multiple brokers or building institutional-grade Automated Trading Systems, that's not a problem to debug alone. With over 9,000 projects completed, the MT4Programming team handles exactly this kind of MQL4/MQL5 timezone logic — from broker compatibility testing to full Expert Advisor validation under live trading conditions. If your session filter needs to hold up across brokers, platforms, or cross-platform conversion scenarios, get in touch for a professional code review.

Key Takeaways

Broker server time is not the same as GMT, UTC, or your local computer time, and confusing them can break time-based trading logic.
Most MT4 brokers operate on GMT+2 during winter and GMT+3 during summer to align daily candles with the New York close.
Daylight Saving Time (DST) transitions can shift trading windows by an hour, causing missed entries, late exits, and inaccurate session filtering.
Daily candle calculations, pivot points, ATR values, moving averages, and other indicators can be distorted when timezone handling is incorrect.
The "Sunday Candle" problem is often caused by brokers using different daily candle boundaries than the strategy expects.
TimeCurrent() returns broker server time, not GMT, making offset calculations essential for reliable session-based trading.
Hardcoded GMT offsets eventually fail when DST changes occur, especially on unattended VPS installations.
Dynamic GMT offset calculations and automated DST detection provide more reliable long-term operation than manual adjustments.
Backtests can appear profitable while live trading fails simply because historical data and live server time operate on different clocks.
Every MT4 Expert Advisor that uses session filters, news filters, daily resets, or time-based entries should include timezone-aware logic from the start.

Frequently Asked Questions

What is the MT4 timezone trap?

The MT4 timezone trap occurs when an Expert Advisor assumes one timezone while the broker server operates in another. This mismatch causes session filters, daily calculations, and time-based trade rules to execute at unintended times.

What timezone do most MT4 brokers use?

Most forex brokers use GMT+2 during winter and GMT+3 during summer. This aligns daily candles with the New York close and helps eliminate unwanted Sunday candles.

Why does my EA trade at the wrong time?

The most common cause is an incorrect GMT offset or missing DST adjustment. If the EA believes London Open occurs at one server hour while the broker uses another, trades will trigger at the wrong time.

What is the Sunday Candle problem?

A Sunday Candle is a short, low-volume candle that appears at the start of the trading week when daily candle boundaries are misaligned. It can distort indicator calculations and produce unreliable trading signals.

Does Daylight Saving Time affect MT4 Expert Advisors?

Yes. DST changes can shift session windows by one hour and create several weeks each year where US and European market clocks are temporarily out of sync. EAs that do not account for DST often experience missed or mistimed trades.

What is the difference between TimeCurrent( ), TimeGMT( ), and TimeLocal( )?

TimeCurrent() returns broker server time, TimeGMT() returns UTC/GMT time, and TimeLocal() returns your computer's local clock. Using the wrong function can introduce timezone errors into trading logic.

Why do backtests look good but live trading performs differently?

Historical data may be based on a different timezone structure than the broker's live server. Without proper offset and DST handling, session filters and entry conditions can operate on different clocks during live execution.

Should I hardcode a GMT offset in my EA?

No. Hardcoded offsets eventually fail when DST transitions occur or when you switch brokers. Dynamic offset calculations combined with DST-aware logic provide a more reliable solution.

How can I verify my timezone logic is working correctly?

Run backtests across known DST transition periods, review trade timestamps, use Visual Mode in the Strategy Tester, and compare actual trade times against intended session windows.

When should I get a professional MT4 code review?

If your strategy relies on session trading, news filtering, multi-broker deployment, or complex time-based rules, a professional review can identify timezone and DST issues before they affect live trading performance.