Broker Server Time: The Clock Your Charts Actually Run On

Open a daily chart and the last bar has a closing time. That time was not chosen by you, and on most platforms it is not your local midnight either.

It belongs to the broker’s trading server, and it decides where every daily and weekly bar is cut, how many bars a week contains, and the moment overnight financing is applied.

What follows is what that clock is, why it usually sits two or three hours ahead of UTC, the weeks when it stops lining up with the New York close, and how to read your own offset instead of trusting a table.

What Server Time Is, and Whose Clock It Is

Every quote your platform receives is stamped by the broker’s trading server. The platform builds bars by grouping those stamped quotes into intervals, and the intervals are cut on the server’s clock.

This is why two traders in different countries, looking at the same symbol from the same broker, see identical bars. It is also why a trader who moves country sees nothing change on the chart.

The consequence worth holding on to is that a chart’s time axis is not a statement about your day. It is a statement about the server’s day, and the two rarely coincide. Where that boundary falls also decides which bar a condition is measured against, although when an alert actually fires follows a separate rule again.

Nothing here is a setting you control. The offset is a property of the server your account lives on, and the only decision available to you is which broker and which account you open. The practical differences between the terminals themselves are covered in MT4 and MT5.

Why the Offset Is GMT+2 in Winter and GMT+3 in Summer

The forex trading day is conventionally taken to end at 5pm in New York, the close of the last major session before the week rolls into the Asian open. Most server clocks are set so that their own midnight lands exactly there.

The arithmetic is short. New York on Eastern Standard Time is five hours behind UTC, so 5pm there is 22:00 UTC. A clock running two hours ahead of UTC reads 00:00 at that moment.

In summer New York moves to Eastern Daylight Time, four hours behind UTC, so 5pm becomes 21:00 UTC. A clock three hours ahead of UTC reads 00:00 then. That is the whole reason the offset changes with the season.

It is worth stating plainly because the pairing is often written down incorrectly. One broker’s own help page gives the MT4 daily close as 5 PM EST (GMT+2), which cannot be read literally: Eastern Standard Time is five hours behind UTC, not two ahead. The two figures describe different clocks, and only the arithmetic above connects them.

Five Daily Candles a Week, Not Six

Trading opens on Sunday evening in New York and closes on Friday evening. That is five 24-hour stretches, so a daily chart should hold five bars for the week.

It only does so if the day boundary sits at the New York close. Move the boundary to 00:00 UTC and the Sunday evening opening falls inside Sunday’s calendar day, producing a short bar of roughly two hours before Monday begins.

The week then shows six bars, one of them a stub built from a thin, illiquid couple of hours. Its high, low and close are real prices, but they describe the quietest part of the week.

This matters more than it first appears. Any method reading the daily close, range, high or low gets a different number depending on where the boundary sits, and a stub bar can register as a spurious signal.

The Weeks the Daily Candle Does Not Close at the New York Close

The alignment above assumes the server changes its offset on the same dates New York changes its clocks. Frequently it does not, because the two regions run different statutory schedules.

In the United States, the Energy Policy Act of 2005 amended the Uniform Time Act so that daylight time runs from the second Sunday in March to the first Sunday in November. In the European Union, Directive 2000/84/EC sets summer time from the last Sunday in March to the last Sunday in October.

Those dates do not coincide. In 2026 the United States moves on 8 March and 1 November, while the European Union moves on 29 March and 25 October.

A server keeping the European schedule therefore spends 21 days in spring, from 8 to 29 March, and a further 7 days in autumn, from 25 October to 1 November, holding an offset that no longer matches New York. That is 28 days in 2026 during which the daily bar closes at 6pm New York rather than 5pm.

The effect is not subtle for anyone reading daily bars. For four weeks a year the boundary sits an hour into the next trading day, so a late move belonging to one session is recorded in the next one’s bar.

This is a conditional, not a universal claim. A server that follows the United States schedule stays aligned all year and shows none of this. Which schedule your own server keeps is a question of fact about your broker, and the next section is how to settle it.

How to Read Your Own Server Offset Off the Platform

There is a widely copied table circulating that lists server offsets for a dozen named brokers. It is worth saying why this page does not reproduce it: the version that ranks best states no source for any row, and a broker can change a server clock without announcing it.

Reading it yourself takes a few seconds and cannot go stale. The Market Watch window displays the server’s own time, so comparing that reading against a known UTC clock at the same moment gives the offset directly.

Do the comparison twice a year, once in each half, if you want to know which statutory schedule the server keeps. A server that changes its offset in the second week of March follows the United States schedule; one that changes at the end of March follows the European one.

The contract specifications for each symbol carry the related settings, including session times and the day financing is charged at a multiple. Those mechanics are covered in the triple swap day; what belongs here is only that the charge fires at the server’s own midnight.

Two Functions Report Server Time and They Disagree

Anyone automating around the clock meets a second problem, and most explanations treat the two available readings as interchangeable. They are not.

MetaQuotes defines the first as the last known server time, specifically the time of the last quote receipt. When no quotes are arriving it does not advance, so on a closed or very quiet market it reports a stale value.

The second is described as the calculated current time of the trade server. It is computed inside the terminal by adding the last known difference between the client and server time zones to the local clock, so it keeps advancing when the market is shut.

The trade-off is worth stating in one line. The first is authoritative but can be stale; the second is continuous but inherits any error in the local computer’s own clock and time zone settings.

So advice to use the first function fails in exactly the situation it is usually needed, deciding whether a session has opened yet. Code scheduling around session boundaries wants the continuous reading, accepting that it trusts the local machine.

What Server Time Changes, and What It Only Relabels

Server time is decisive in a narrow set of cases and close to cosmetic everywhere else, and separating the two saves a lot of unnecessary worry.

It is decisive if you read daily or weekly bars, because the offset determines where each bar is cut and therefore which high, low and close it records. It is decisive for backtesting, because a strategy tested on bars cut in one place is not the same strategy on bars cut in another.

It is decisive for anything keyed to a session boundary, and for judging where a scheduled release lands, which is treated at length in economic calendar release times. The sessions themselves are set out in forex market sessions.

It is close to cosmetic on five-minute and fifteen-minute discretionary charts. The offset shifts the labels on the time axis but the bars group the same quotes into the same shapes, so a pattern does not appear or vanish because the axis is annotated differently.

The one qualification is that a higher timeframe read alongside a lower one inherits the boundary problem, which is part of why the relationship between timeframes is handled carefully in multi-timeframe analysis.

Who This Page Is Not For

If you trade intraday off short timeframes and never reference a daily close, a daily range or a session boundary, the server offset is a labelling detail and acting on it changes nothing.

This page also does not identify a correct or best server offset, because there is not one. An offset is neither an advantage nor a defect; it is a fact about where bars are cut, and a method either accounts for it or does not.

Nothing here evaluates brokers or suggests changing one. A server clock is a poor reason to move an account.

Frequently Asked Questions