A daily candle is a container. It holds every tick between one arbitrary cut-off and the next, and the position of that cut-off is set by the broker's server clock, not by anything in the market. Move the cut-off by an hour and the open, the close, the high and the low can all change. The wick that made a pin bar in one feed becomes the body of an ordinary candle in another.
Most retail forex servers run on a GMT+2 or GMT+3 clock, chosen so that the daily candle closes at the 17:00 New York settlement hour. That choice gives you five daily candles per week instead of six, because the thin Sunday evening session gets folded into Monday rather than becoming its own stub bar. Brokers that run their servers on plain UTC produce six daily candles, and the sixth one is a few hours of quiet Asian liquidity that most textbooks never account for.
Where the offset actually comes from
Three clocks are in play and traders routinely confuse them. The first is the server clock, which stamps every tick and decides where bars begin. The second is your computer clock, which the terminal uses for alert scheduling and for anything you type into a calendar. The third is the exchange or session clock you have in your head when you say "the London open".
Only the first one builds candles. The terminal usually shows server time in the chart's time axis and local time in the operating system tray, which is why a trader in Singapore can see a candle labelled 09:00 that has nothing to do with nine in the morning anywhere near them. That is not a bug. It is the terminal being honest about which clock owns the data.
The offset also moves twice a year. Servers pinned to a New York close follow US daylight saving transitions, which happen on different dates from European ones. For roughly two weeks in March and again in late October, the gap between a European trader's wall clock and the server clock is one hour different from the rest of the year. Levels drawn on a session boundary drift by exactly that hour, and traders who use fixed session boxes see them land in the wrong place until they adjust.
What it changes in practice
The damage is concentrated in anything that depends on where a bar starts or ends. Daily opens and previous-day highs and lows shift. Pivot points, which are computed from the prior daily high, low and close, land on different prices. Any rule that says "wait for the daily close" fires at a different moment. Strategies built on the London breakout or on the first hour of a session are drawn from bar boundaries, so a one-hour offset can mean you are boxing the wrong hour entirely.
If you copy levels from a chart in a video or a signal channel, ask what server the chart came from before you draw them on your own. Two GMT+3 charts agree. A GMT+3 chart and a UTC chart do not, and the disagreement is largest on exactly the volatile days you care about.
Weekly candles inherit the same problem and amplify it. A weekly bar on a GMT+2 server opens on Monday morning European time. On a UTC server it opens Sunday evening. That Sunday evening stretch carries the reaction to weekend news, and it often contains the week's low or high in a gap scenario, which is why gap handling differs so much between platforms.
Making your charts agree with something
You do not need every platform to match. You need to know which convention you have chosen and stay on it. Charting tools let you set a display time zone independently of the data, and a common choice is to show everything in UTC so that economic releases, which are published in UTC or in a named local zone, line up without mental arithmetic. Another common choice is New York time, since the daily close convention is already anchored there.
What matters more is bar construction. Changing the display label does not rebuild the bars. If your platform draws daily candles from a GMT+3 server, selecting "display in UTC" moves the labels but leaves the same candles. Only a platform that builds bars from raw ticks with a configurable session start can genuinely give you a different daily candle, and most retail terminals cannot. Traders who need a specific close either pick a broker whose server matches or work on a lower timeframe and aggregate themselves.
The alert and automation side
Automation is where the mismatch turns expensive. An expert advisor that checks "is it after 08:00" is reading server time, while a webhook alert configured in a charting tool may be scheduled against the chart's display zone. Wire those two together and you get a system that behaves correctly for eight months and then quietly shifts by an hour when one side changes for daylight saving. If you build alerts through TradingView webhooks, put an explicit timestamp in the payload and have the receiving side reject anything outside a sanity window rather than trusting the clock it happens to be running on.
News automation has the same failure. Economic calendars publish release times in a stated zone, and calendar feeds usually carry a UTC field alongside the display string. Read the UTC field. Anything that parses the display string is one policy change away from firing an hour early, which around an NFP release is the difference between a working filter and no filter at all.
How to check yours in two minutes
Open a one-hour chart and hover the most recent candle. Note the label. Now check the actual UTC time from any clock you trust. The difference is your server offset, and it is worth writing down next to your platform's name. Do it again in November and in March, because the number changes. On our own eTrader builds we surface the server clock in the interface for exactly this reason: a trader who cannot see which clock built the bar cannot check whether a level came from the same one.
Then compare the daily candle count over the last two weeks. Five candles per week means a New York close convention. Six means UTC with a Sunday stub. That single count tells you more about how your platform reads than most platform comparison tables, and it takes less time than reading them. Anyone moving between platforms should run the check before assuming a strategy transferred cleanly, alongside the usual questions about timeframe behaviour.
"If your daily candle closes at a different hour than the person you are learning from, you are not trading their strategy. You are trading a lookalike."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Daily and weekly candles are built from the broker server clock, so the same pair can print different bars on two feeds.
- Five daily candles a week means a New York close convention; six means a UTC server with a Sunday stub bar.
- The server offset changes twice a year when US and European daylight saving dates fall apart by up to two weeks.
- Changing the display time zone relabels bars, it does not rebuild them, so pivots and daily opens stay where the server put them.
Frequently Asked Questions
Why does my broker's chart show a different time from my computer?
The chart time axis uses the broker's server clock, which stamps incoming ticks and decides where each bar begins. Your computer tray shows your own local zone. Most retail forex servers run at GMT+2 or GMT+3 so the daily bar closes at the New York settlement hour.
Does changing the chart time zone change my candles?
No. Switching the display zone moves the labels on the time axis but the bars are still built from the same server session boundaries. To get genuinely different daily candles you need a platform that builds bars with a configurable session start, or a broker whose server uses the convention you want.
Which time convention should I use for drawing levels?
Pick one and stay on it. Traders who follow economic releases often work in UTC because calendar feeds publish UTC timestamps. Traders who follow daily opens and pivots often work in New York time because the daily close convention is anchored there. Consistency matters more than the choice.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.