The broker’s clock is not UTC
13 min read · Published 28 Oct 2026
The time next to a candle on the chart is the broker’s server time, not universal time and not Polish time. In three months we mixed up these clocks at least nine times: in backtests, in automated systems running live, and even in our own rule that was supposed to protect us from exactly this. In a New York session breakout test, the error shifted every session by 2–3 hours and gave itself away with an odd count: the strategy produced 3 trades, the placebo 127. The cheapest check turned out to be a single question: at what time of day does gold move the most?
Abbreviations: UTC is Coordinated Universal Time, the reference from which all time zones are counted. Placebo is the same procedure run at moments when the cause under study is absent. R is a trade’s result in units of risk (−1 R = a loss equal to the distance to the stop). M5 means five-minute candles. Daylight saving time in the US and in Europe starts and ends on different days.
The assumption nobody checks
The trading platform stores the date and time of every candle as the number of seconds since 1 January 1970, the same format used for real universal time. So it is natural to assume that it is UTC. In fact, the data from the terminal hold the wall-clock time of the broker’s server, labeled as if it were UTC. No program will raise an error over this. The number looks right and the dates match; only the hours are shifted.
At our broker, the server runs on a “New York + 7 hours” rule. It is a popular convention: server midnight falls at 17:00 in New York, when the trading day on the currency market ends, so a week has five daily candles, with no short Sunday candle. In winter this gives UTC+2, in summer UTC+3, and the clocks change together with the US, not with Europe.
Four clocks can meet in a single test:
- the broker’s server clock, in which the candles and ticks are recorded;
- real UTC, used by exchange data, external calendars and the system clock;
- the time zone of the computer the program runs on (in our case Central European Time);
- the economic calendar built into the terminal, which for us records times in a fixed UTC+3 all year round, so in winter it is an hour “later” than the candles.
For a trader in Poland, the difference is not constant either. For most of the year the server is one hour ahead of Polish time, but for 3–4 weeks a year (in March and around the turn of October and November), when the US and Europe are on different time, the difference is two hours. The US jobs report always comes out at 8:30 in New York and at 15:30 on the server clock, but in Poland sometimes at 14:30 and sometimes at 13:30.
How it came to light
The opening range breakout test on gold (22 Sep 2026). We describe it in chapter 10. We set the sessions in UTC: London from 8:00, New York from 13:30. The first run treated candle times as UTC. The New York session gave 3 trades in six years, while the placebo, the same rule on the range from 16:30, gave 127. When the placebo is forty times “more active” than the signal, the problem lies in the measurement, not in the market.
The explanation was simple. Our “13:30 UTC” was in reality 13:30 on the server clock, that is, 6:30 in New York and 12:30 in Poland: a quiet time before the US open, with narrow ranges that almost never passed the width filter. Meanwhile, 16:30 on the server clock is exactly 9:30 in New York, the opening of the stock market there. So the placebo landed on the real open, and the “signal” on the quiet. The error was given away by a check that we have run in every session-based test since: gold’s volatility peak fell at 16:00 by the server clock, which converted to UTC is around 14:00, during the hours of data releases and the opening of trading in New York.
The macro data surprise test (17 Sep 2026, error found on 27 Oct). We describe it in chapter 26. The terminal’s calendar records times in a fixed UTC+3. In summer this matches the candles; in winter it does not. The US jobs report always comes out at 15:30 on the server clock, but in our file it sat at 16:30 in January, February and early March. So for 39 of the 90 events in the training sample we were measuring a window that began an hour after the release. The clock check before the test gave 19 matches out of 19, but it covered only August and September. In the full calendar export for 2017–2026, the same report sat at 16:30 as many as 80 times before the correction, and after the correction at 15:30 in 115 cases out of 116.
The news-release scalping system (20 Aug 2026). It ran in observation mode, without placing orders. It compared calendar times, recorded in server time, with the computer’s clock, which was an hour behind. So it armed itself exactly one hour after the release. The system’s owner noticed it: the system armed at 15:30, while the data had come out at 14:30.
Before the error came to light, four “late” observations had turned out profitable. This gave rise to a hypothesis that an hour after the data, the market continues its move. We tested it with criteria written down before the test, on 120 events and two instruments. Entering an hour after the release gave an average of −0.15 R on gold and −0.31 R on bitcoin, worse than a placebo two hours before the release (−0.06 R and +0.03 R). The four profitable observations were plain luck. While writing this chapter, we found a smaller error of the same family in that test. Events were converted through a European time zone, so 10 of the 120 (those in the weeks between the clock changes in the US and in Europe) landed an hour before the correct moment. It does not change the conclusion, but it shows well how stubborn this error is.
Our own rule (25 Sep 2026). After the 22 Sep test we wrote into our rules that we convert the server clock through the Athens time zone, that is, UTC+2 or UTC+3 with the European clock change. Three days later we compared hourly changes in the gold price at our broker with the gold futures contract, whose times the exchange gives in real UTC, over about 38,000 hours from 2020–2026. In March, October and November the “New York + 7 h” rule matched the two series clearly better (median discrepancy 0.18 against 0.28), and in the other months both variants came out the same. So our rule was off by an hour for 21–28 days a year; in 2026 these were 8–28 March and 25–31 October.
Result: nine mistakes of one family
| when (2026) | where | what we mixed up | effect | how it came to light |
|---|---|---|---|---|
| 28–29 Jul | code of the running system (6 places) | candle time taken for real UTC and additionally shifted by the computer’s time zone | hours shifted by 5 h, trades assigned to the wrong days | among other things, a daily settlement that did not match the account balance (4 Aug) |
| 20 Aug | news-release scalping system (observation) | calendar in server time vs. the computer’s clock | arming an hour after the data; 4 falsely profitable observations | the system’s owner compared the times |
| 30 Aug | closing positions before the weekend | schedule in computer time, market in server time | start 46 minutes after the market closed; rejected orders with no trace in the log for several weeks | analysis of “market closed” rejections |
| 17 Sep | macro surprise test | calendar (fixed UTC+3) taken for the candle clock | in winter, a window an hour after the release: 39 of 90 events | reading the code while writing chapter 26 |
| 22 Sep | opening range breakout test on gold | candle time taken for UTC | sessions shifted by 2–3 h; signal 3 trades, placebo 127 | odd counts and a volatility peak at 16:00 |
| 25 Sep | our rule from 22 Sep | Athens time zone instead of “New York + 7 h” | 1 h error for 3–4 weeks a year | comparison with the futures contract |
| 2 Oct | downloading ticks for one example | date without a time zone in the query, the program assumed computer time | window 2 h too early; “target hit” before the entry | the time of the result fell before the entry |
| 6 Oct | the same scalping system | external calendar hard-coded at UTC+3, “now” in a European time zone | from 25 Oct to March it would again have armed an hour after the data | code review before the clock change |
| 27 Oct | opening range breakout test (rereading) | session hours in fixed UTC all year | on 59% of days “London” started an hour after the open, on 35% of days “New York” fell on the minute of a data release | reading the code while writing chapter 10 |
Two cases in the table changed a test result enough that its conclusion was no longer valid (17 Sep and the first run of 22 Sep). Two concerned the running system: daily settlement (28 Jul) and closing positions before the weekend (30 Aug). We caught the rest before they affected a decision, but only because something looked odd.
Why this error keeps coming back
It raises no exception. The program runs, the numbers are plausible, the sessions exist; they just sit in the wrong place. The result from a shifted session is not absurd. It is simply the result of a different strategy.
It often hides in a season nobody checked. The calendar error occurred only in winter, and the check covered summer. The Athens time zone error lasts 3–4 weeks a year. Checking one day or one month will not catch it.
A fix is often partial. After the 20 Aug fix, the system calculated “now” in a European time zone, so from the end of October it would again have armed an hour after the data (caught on 6 Oct), and the test written the same day shifted 10 events out of 120. The 22 Sep rule fixed the 2–3 hour error but left a one-hour error for several weeks a year. Each time, we considered the matter closed.
Knowledge did not become a rule. We had known since July that time from the terminal is the server clock labeled as UTC. A report from one of the tests on 14 Aug said so explicitly, and that test calculated correctly. But that knowledge stayed in one report and never made it onto our list of rules, so on 22 Sep we made the error all over again and “discovered” it a second time. Since that day we have had a rule: a lesson from a report goes onto the list of rules, or it is lost.
The volatility-peak check catches big errors, but not small ones. A peak calculated in UTC over the whole sample, with summer and winter together, falls in the right place even when the clock is off by an hour for several weeks a year. A shift of 2–3 hours shows up immediately. An hour that affects only part of the year shows up only in a check done separately for each season.
The lesson for you
If your strategy has anything to do with the time of day (a session, an open, a data release, “I don’t trade at night”), the clock is the first suspect, before you even start judging the result.
How to check the clock yourself:
- Compare the time of the current candle with real UTC from any reliable online clock. Do it now, and again after the clocks change in the US and in Europe.
- Find the volatility peak separately for summer and winter, in New York time. Calculate the average range of an M5 candle in each half-hour slot. For gold and US indices, the peak should fall between 8:30 and 10:00 New York time in both seasons. In one of our later tests, a similar measurement (the number of ticks), done separately for summer and winter, showed the activity peak at the US index open at 16:30 server time in both seasons, exactly where it should be.
- Use a known event as a reference. The US jobs report always comes out at 8:30 in New York. Check a few dates in winter, in summer and in the weeks between the clock changes.
- Treat the calendar and the chart as two different sources. If a release “moves” by an hour in the calendar between seasons, the calendar and the candles are in different time zones, and one has to be converted to the other.
- Set sessions in the exchange’s local time, with its daylight saving changes. A single UTC hour all year round is in practice two different sessions: a summer one and a winter one.
- State the time zone explicitly in every data query, and after downloading, print the first and last timestamps of the data and compare them with the window you expected.
- When a count looks odd, check the clock first. A signal with 3 trades next to a placebo with 127 is a symptom of a measurement error, not a feature of the market.
In your trading journal, record trade times in one named time zone, for example Polish time or UTC, and note which one. Without that, comparing results with sessions or release times is a measurement in the wrong place. The “Luck or edge?” calculator will then help you judge whether the difference between sessions goes beyond chance.
Educational content, not investment advice. Past results do not guarantee future results. We describe errors in our tests and in our system, on our data and at our broker; the server clock convention may be different at another broker.