Exness Trading Hours — Server Time and Your Own Records — Nepal

The clock these rows are counted in

Each row below is one hour of the platform server clock — the same clock the terminal writes into every order and every bar. Local time appears nowhere in the table, and on a UTC+05:45 offset the two scales never share a boundary, so a row read as though it were a local hour describes a different stretch of the day than the one you remember trading.

One instrument, hour by hour, on the server clock

Spread = average of all quotes captured in that hour over the last 24h; movement = average high–low of that hour over the last 7 sessions. Both are bucketed by the server hour, which is why a note written at nine in the evening local time does not sit in the row you would expect.

All instruments, on the same clock

Spread in pips (points for non-FX). Every hour named in this table is a server hour; turning one of them into a local hour is a subtraction you do once and then write down.

What a 45-minute offset does to a journal

The damage is quiet, because nothing ever refuses to open. A record that says the entry was taken at nine in the evening is perfectly readable; it simply does not point at any row of the table above, and it does not point at a bar on the chart either. A local hour sits across two server hours at once, so the phrase “the hour I traded in” stops having a single answer the moment the journal leaves the terminal.

Day boundaries go first. A record written just before local midnight and one written just after it can belong to the same server day, and two records that feel like the same evening can land on different sides of the server date line. Anything counted per day - how many entries were taken, how the day ended, which day a position was opened on - inherits that error without showing it.

Weekly and monthly summaries inherit it a second time. A week cut on local Sunday and a week cut on the server week contain different sets of trades, and the two totals will never reconcile no matter how carefully each one is added up. The arithmetic is fine; the period is not.

The one-scale rule

Pick one clock and write everything in it. Which one matters far less than the fact that there is only one, and the practical choice is the server clock, because it is the clock the platform already uses for order times, for the time axis of every chart and for the history statement. A journal on the server clock lines up with a screenshot without any arithmetic at all.

Write the scale down where it cannot be lost - at the top of the page, in the header of the spreadsheet, in the file name. An undated scale is the reason old journals become unusable: the entries survive, the convention does not, and a year later there is no way to tell which hour was meant. A single line saying which clock the file is in costs nothing and saves the whole file.

Local time still has one honest job: alarms and reminders, which belong to the day you actually live in. Keep them, but set them from a converted hour, and keep them out of the record itself. The rule is not that local time is forbidden - it is that a record never carries two clocks at once.

Converting the entries you already have

Do it once, on a copy, and never in place. Work through the old file from the oldest entry forward, put the converted hour in a new column next to the original rather than over it, and mark the file as converted when you finish. The original column is what lets you find the mistake later if the conversion turns out to be wrong.

Prefer a recorded timestamp to arithmetic wherever one exists. The trade history inside the platform already carries the server time of every order, so an entry that can be matched to a real order should be corrected from that record instead of from a subtraction. Arithmetic is for the entries that have nothing to match against.

Where arithmetic is unavoidable, remember that only one side of the offset is fixed. Nepal Standard Time does not change through the year, so the local half is a constant; a server that follows a seasonal clock moves twice a year, and one fixed number applied to a whole archive will be wrong for part of it. Read the current offset from the terminal itself, note the date you read it, and convert older stretches separately.

Putting a journal back on one scale

1. Decide which clock the journal runs on and write that decision at the top of the file before touching a single entry.
2. Read the current server time from the terminal rather than assuming an offset, and write down the date on which you read it.
3. Copy the old file. All conversion happens on the copy; the original stays untouched as the reference.
4. Add a new column for the converted hour instead of overwriting the one you already have.
5. Correct from recorded order times wherever an entry can be matched to a real order in the trade history.
6. Convert the remaining entries by arithmetic, in stretches, and note the offset used for each stretch.
7. Re-cut the daily and weekly summaries on the new scale, because the old totals were counted on the old boundaries.

Nothing here has to be finished in one sitting. What matters is that a single file never ends up half converted with no way to tell which half is which.

Which clock is each of these written in

The middle column is the whole problem. Every row is readable on its own; only the mixture is unusable.

Related Exness pages