Clock drift: when the VPS thinks it's a different second
Posted: Sat Oct 31, 2026 9:52 pm
For news trading, timing is everything. A script that fires an order at 8:29:59.8 needs a clock that's accurate to within milliseconds. Many computers aren't.
Windows synchronizes its clock with a time server only periodically, often once a week by default. In between, the clock can drift by a second or more. A VPS can have its own issues, with virtualized clocks that drift faster.
An order scheduled for the second before a release but sent a second late lands in the middle of the spread explosion. An order sent a second early might trigger before the data and get a poor fill.
The fix is to run a time synchronization tool that updates frequently, ideally with a reliable source. Checking the offset against a reference clock and against the broker's server time reveals the error.
Broker server time and local time can also differ by seconds. Logging both, and comparing at the moment of an order, shows the real delay.
For manual trading, a second's error doesn't matter. For automated news systems, it determines whether the logic works.
Server time offsets add another layer. Some brokers' servers run a few hundred milliseconds ahead of or behind true time, so an order that appears to leave at exactly the right second still lands late or early compared to the market's actual clock. Logging the broker's server timestamp on the order confirmation against a reference time source reveals the offset.
For strategies that need precision, such as placing orders in the second before a scheduled release, the combined clock error from the PC, the VPS, and the broker can reach a second or more. Measuring and correcting for it takes an afternoon and removes a hidden source of randomness.
How far off is the VPS clock from a reference, and has it ever caused a mistimed order?
Windows synchronizes its clock with a time server only periodically, often once a week by default. In between, the clock can drift by a second or more. A VPS can have its own issues, with virtualized clocks that drift faster.
An order scheduled for the second before a release but sent a second late lands in the middle of the spread explosion. An order sent a second early might trigger before the data and get a poor fill.
The fix is to run a time synchronization tool that updates frequently, ideally with a reliable source. Checking the offset against a reference clock and against the broker's server time reveals the error.
Broker server time and local time can also differ by seconds. Logging both, and comparing at the moment of an order, shows the real delay.
For manual trading, a second's error doesn't matter. For automated news systems, it determines whether the logic works.
Server time offsets add another layer. Some brokers' servers run a few hundred milliseconds ahead of or behind true time, so an order that appears to leave at exactly the right second still lands late or early compared to the market's actual clock. Logging the broker's server timestamp on the order confirmation against a reference time source reveals the offset.
For strategies that need precision, such as placing orders in the second before a scheduled release, the combined clock error from the PC, the VPS, and the broker can reach a second or more. Measuring and correcting for it takes an afternoon and removes a hidden source of randomness.
How far off is the VPS clock from a reference, and has it ever caused a mistimed order?