There are three clocks involved in every automated trade, and only one of them stamps your charts. Most time related confusion in MetaTrader comes from assuming there is just the one.
Key Takeaways
- Charts and history are stamped in broker server time. Not your time, not the VPS time.
- Changing the Windows clock changes nothing in the terminal. It only breaks your logs.
- The broker’s offset moves twice a year, often on the US daylight saving schedule rather than yours.
- A fixed hour in an EA input is a fixed hour in server time, so the window shifts when the broker does.
- Write the offset down, with the date you checked it.
1. The Three Clocks
Your local time is what you read on your own screen. It is the one you think in and the one your notes are written in, and it has no bearing whatsoever on the platform.
The VPS clock is Windows time on the server. It governs Windows event logs, scheduled tasks and file timestamps. It matters for administration and for nothing else here.
Broker server time is what MetaTrader displays. Every candle, every entry in the history tab and every line of your statement is stamped with it. When an EA calls for the current time it gets the server’s, not the machine’s.
These do not have to agree, and usually they do not. A trader in London running a VPS in New Jersey on a broker whose servers sit at GMT+3 is looking at three different clocks at once, which is fine as long as you know which one you are reading.
2. Why This Trips People Up
The confusion is almost always the same shape. Something looks wrong in the platform, the trader checks the VPS clock, finds it correct, and concludes the platform is broken.
The VPS clock being right is not evidence of anything. It is not the clock that stamped the chart.
A related version: a trader changes the Windows time zone to match the broker, expecting the charts to line up. Nothing moves, because nothing in MetaTrader was ever reading it. What they have actually done is make the server’s own logs disagree with real time, which makes the next problem harder to diagnose.
3. Where the Day Starts
The broker’s offset does more than shift the labels. It decides where the trading day breaks, and that changes what your charts contain.
A broker at GMT+2 or GMT+3 has a day boundary that folds the Sunday session into Monday’s candle, so the week prints five daily candles. A broker at or near UTC prints a separate short Sunday candle, so the week has six.
Anything that counts days is affected: daily ranges, previous day high and low, day of week filters, and any indicator with a lookback expressed in days. The same strategy on two brokers with different offsets is not running on the same data, even with an identical price feed.
This is also why a backtest can look different from live trading after a broker change. Nothing about the logic moved. The day boundary did.
4. The Offset Moves Twice a Year
Broker server offsets are not fixed. Most shift with daylight saving, and here is the part that catches people out: many follow the US daylight saving calendar, not the European or UK one.
For two or three weeks each spring and autumn, the gap between your local time and the broker’s server time is not what it was the month before. If you are in the UK or Europe, your clocks and theirs change on different dates.
The practical effect is that any rule written as a fixed hour of server time keeps doing exactly what it was told, while the moment in real time that it refers to has moved. An EA that trades the London open at a hard coded server hour will start trading an hour early or an hour late, and there is nothing in its log to suggest anything unusual happened.
5. Finding Your Broker’s Offset
The quick manual check: open Market Watch in MT4 or MT5 and read the time at the top. Compare it to the current UTC time. The difference is your broker’s offset.
In code, TimeGMTOffset() returns the difference between local and GMT time, and TimeCurrent() returns the last known server time. For a manual check the Market Watch reading is faster and less prone to being misread.
Then count the daily candles in a normal trading week. Five tells you the boundary folds Sunday into Monday. Six tells you the server sits close to UTC.
Write both down, along with the date you checked. Six months later, when a strategy behaves oddly, having a recorded offset from a known date is the difference between a two minute check and an afternoon.
6. Making Time Based Rules Survive the Change
If your strategy has any time component, a few habits make the twice yearly shift a non event.
Express windows in server time deliberately, not by accident. Decide that an input means server hours, document it in the input name or a comment, and stop converting in your head.
Anchor to sessions rather than clock hours where the logic allows it. A rule that keys off the broker’s day boundary is stable across an offset change in a way that a hard coded hour is not.
Put a reminder in late March and late October. Check the offset, confirm your windows still land where you intended, and adjust the inputs if they do not. This takes a minute and prevents the class of problem that otherwise gets diagnosed as a broken EA.
Do not touch the VPS clock. Leave Windows on correct time, synchronised properly. The value of a correct machine clock is that your logs, your scheduled tasks and your Windows events all agree with reality when you need to reconstruct what happened.
7. Reading Your Own Records
One last place this shows up. Your statement and the terminal’s history tab are in server time. A journal you keep yourself is almost certainly in your local time.
Reconciling the two months later, with a daylight saving change somewhere in the middle, is genuinely unpleasant. If you keep any record of your trading outside the platform, note the offset next to it. Your future self will be grateful for the one extra field.