Chart time, server time, order time: three clocks
Posted: Sat Oct 31, 2026 1:48 am
A platform shows time in at least three ways, and mixing them up leads to subtle errors.
Chart time is the timestamp on each bar, based on the server's time zone. Order time in the history window can be server time as well, or local time, depending on the platform. The operating system's clock is a third. And the exchange or data source that releases the news has its own.
When the 8:30 release hits and a spike appears on the chart at 15:30, it's because the server is on GMT+3 in summer. When reviewing trades after a news event, matching the order time to the right bar requires knowing which clock is in use.
Another trap is clock drift. A computer whose clock is off by two seconds will show orders at times that don't match the server's record. That makes analysis of latency and slippage meaningless. Syncing with an NTP server is simple on most systems and takes less than a minute.
Logging a screenshot or a note of the local time, server time and event time on a data release day sets the reference. Once that's known, all the other times can be converted.
Without it, a review of a news trade can lead to completely wrong conclusions about what happened and when.
One more clock can cause trouble: the broker's own statement time zone. Daily statements may cut off at a time that doesn't match the server's day, so trades near midnight server time can be assigned to the wrong day in reports. When reconciling performance by day, checking the statement's cutoff avoids phantom discrepancies.
Has a time mismatch ever made a trade review point to the wrong conclusion?
Chart time is the timestamp on each bar, based on the server's time zone. Order time in the history window can be server time as well, or local time, depending on the platform. The operating system's clock is a third. And the exchange or data source that releases the news has its own.
When the 8:30 release hits and a spike appears on the chart at 15:30, it's because the server is on GMT+3 in summer. When reviewing trades after a news event, matching the order time to the right bar requires knowing which clock is in use.
Another trap is clock drift. A computer whose clock is off by two seconds will show orders at times that don't match the server's record. That makes analysis of latency and slippage meaningless. Syncing with an NTP server is simple on most systems and takes less than a minute.
Logging a screenshot or a note of the local time, server time and event time on a data release day sets the reference. Once that's known, all the other times can be converted.
Without it, a review of a news trade can lead to completely wrong conclusions about what happened and when.
One more clock can cause trouble: the broker's own statement time zone. Daily statements may cut off at a time that doesn't match the server's day, so trades near midnight server time can be assigned to the wrong day in reports. When reconciling performance by day, checking the statement's cutoff avoids phantom discrepancies.
Has a time mismatch ever made a trade review point to the wrong conclusion?