GMT Offset & DST: The Silent Backtest Killer

The Standard, and Why It Exists

Two verified facts every backtester should hold (Tick Data Suite documentation, whose default is exactly this for exactly this reason):

1. The vast majority of forex brokers run server time at GMT+2 with US DST — it’s the de facto industry standard.
2. A broker showing GMT+3 from late spring to early autumn is almost never “a GMT+3 broker” — it’s a GMT+2 broker with daylight saving active.

Why GMT+2? Because then 00:00 server time = 5 pm New York — the institutional close of the forex day. The daily candle spans exactly one trading day, the week contains five daily candles, and Sunday’s thin pre-open hours fold into Monday. On feeds with other offsets (GMT+0 is common in some data sources), the week prints a sixth, stubby “Sunday candle” and every daily open/high/low/close differs — which changes daily-level support/resistance, daily indicators, and any “yesterday’s high” logic.

The Failure Mode

Your strategy says “trade the London open” or “no entries after 16:00” or “box the 08:00–10:00 range” (our worked-example strategy does exactly this). Those rules are clock-anchored. If the backtest data’s clock isn’t what you assumed:

• The rules fire one hour off — and because DST shifts twice a year, the error is seasonal: correct half the year, wrong the other half, depending on when your assumption matches reality.
• Nothing looks broken. Charts render normally, trades still happen — the backtest simply tested a different strategy than the one you’ll trade.
• Bonus trap: US and UK DST changes don’t coincide (they diverge for ~2–3 weeks each spring and autumn), so “London open” drifts relative to a US-DST server clock during exactly those weeks — see sessions & timezones.

The signature of a DST bug in results: a time-window strategy whose performance differs sharply between summer and winter halves of the backtest. That’s rarely the market being seasonal; it’s usually the clock being wrong for one of the halves.

Detection: Find Your Data’s Real Offset in 2 Minutes

1. The Sunday-candle test. Open the daily chart. Five candles per week → GMT+2/+3-style feed. Six (one tiny) → a different offset (often GMT+0); your daily levels and any session math need re-anchoring.
2. The rollover test. Find the minutes of maximum spread widening / the daily price gap on an intraday chart (rollover artifacts). On a GMT+2/+3 feed they cluster around 00:00 server time. Wherever they cluster on yours — that’s your server’s midnight.
3. The news test. Locate a known event (e.g. NFP: 8:30 am New York). On a GMT+2/+3 server it prints at 15:30 server time (both clocks shift with US DST together). If it prints elsewhere, compute the offset from the difference.

Then write the offset into the backtest’s header notes, express every session rule in server time, and re-run the detection whenever you change data sources.

Related: sessions & timezones · broker feed differences · gaps & rollovers

Frequently Asked Questions

Why don't brokers just use GMT or the trader's local time?

Because the forex day institutionally ends at 5 pm New York. A GMT+2-with-US-DST server clock makes that moment exactly midnight year-round, which keeps each daily candle equal to one trading day and the week at five candles. Local-time charts would fragment days differently for every trader.

Does this matter for strategies without time rules?

Less, but not zero: the server clock decides where daily candles split, so daily opens, closes, highs/lows — and every indicator computed from them — differ across offsets. Pure intraday structure trading on execution timeframes is least affected; anything referencing daily levels inherits the clock.

My replay tool doesn't say what timezone its data uses. What do I do?

Run the detection tests on the data itself — the Sunday-candle count and the rollover-spread cluster reveal the offset in minutes, no documentation needed. Then anchor your session rules to what the data actually does rather than what any setting claims.

Which weeks of the year are most dangerous for session strategies?

The DST divergence windows: roughly mid-March to late March and late October to early November, when the US has shifted but the UK/EU hasn't (or vice versa). During those weeks, London-anchored behavior moves by an hour relative to a US-DST server clock — backtests spanning years should expect those weeks to look slightly different.