Clock Drift and Trade Timestamps: Why Your Logs Disagree With Your Broker

Your copier log says the order left at 14:30:00.100. The broker's fill report says 14:30:00.060. Read literally, the fill landed 40 ms before you sent the order. That is what happens when two machines each keep a private count of seconds, and it corrupts every latency number, fill dispute and breach timeline you build on top of it.

Why do timestamps in a trading stack disagree at all?

Because every machine keeps time on its own free-running quartz oscillator, and no two oscillators run at the same rate. Your terminal, your VPS, the copier server, the broker gateway and the exchange matching engine hold five separate counts. Left undisciplined, those counts separate continuously and never reconverge.

RFC 5905 fixes PHI, the maximum disciplined system clock frequency tolerance, at 15 parts per million, and the RFC itself notes this amounts to about 1.3 seconds per day. The arithmetic: 86,400 x 0.000015 = 1.296 seconds, while a commodity crystal spec'd at 50 ppm would give 4.32 seconds. NTP uses that figure as the rate at which its error estimate grows once a clock loses its sources, so read those numbers as the price of discipline stalling, not what a healthy box does nightly.

Kill one misconception: same data centre does not mean same time. Two racks in one building drift apart at the same rate as two machines on different continents unless both are disciplined against a reference. Colocation buys transit time. It does not buy you time.

What single symptom proves your clocks are unsynchronized?

An effect that appears to precede its cause. It is the only fully diagnostic symptom here, not a merely suggestive one, because causality does not break and packets do not arrive before they are sent. Negative elapsed time across two machines is not latency. It is clock offset, and you can bound it.

Work the opening example. Apparent elapsed time is 0.060 minus 0.100, or minus 40 ms. Add one constraint: minimum one-way transit to the broker gateway is 12 ms. Let theta be how far your clock reads ahead of the broker's. On the broker's timescale your send happened at 14:30:00.100 minus theta, and the fill cannot land earlier than 12 ms after that, so 0.060 must be at least (0.100 minus theta) plus 0.012. Rearranged, theta is at least 0.100 + 0.012 - 0.060 = 0.052 seconds. Your clock runs at least 52 ms ahead, derived from two log lines and one transit floor.

How does NTP actually set your clock?

It measures the round trip to a time server and splits it in half. Per RFC 5905, the protocol exchanges four timestamps: T1, the client time the request departed; T2, the server time it arrived; T3, the server time the reply left; T4, the client time the reply arrived. Round-trip delay is (T4 - T1) - (T3 - T2), and clock offset is theta = 1/2 x [(T2 - T1) + (T3 - T4)]. The RFC states the goal plainly: minimize both the time difference and the frequency difference between UTC and the system clock. NTP disciplines to UTC, never to your local time zone.

Concretely. T1 = 14:30:00.000, T2 = 14:30:00.058, T3 = 14:30:00.059, T4 = 14:30:00.101. Delay = 0.101 - 0.001 = 0.100 s. Offset = 1/2 x [0.058 + (0.059 - 0.101)] = 1/2 x [0.058 - 0.042] = 1/2 x 0.016 = 0.008 s. NTP concludes the server is 8 ms ahead and nudges the local clock.

Now attack the averaging step. Halving the round trip is only correct if the request leg and the reply leg take equally long. Suppose the real path is 80 ms out and 20 ms back, because your uplink is congested while the downlink is idle. The round trip is still 100 ms, so NTP sees an identical measurement and computes the identical 8 ms. But the request really arrived at client-time 14:30:00.080 while the server stamped it 14:30:00.058, so the server is truly 22 ms behind the client. NTP is wrong by 0.008 - (-0.022) = 0.030 seconds. The closed form is unforgiving: error equals (outbound - return) / 2, here (80 - 20) / 2 = 30 ms exactly, bounded only by half the round-trip time.

Nothing in the protocol can detect it. The client sees T1 and T4 on its own clock and T2 and T3 on the server's, so a fast request paired with a slow reply is arithmetically identical to a symmetric path plus a real offset. An asymmetric route poisons a clock while every status command still reports "synchronized".

What accuracy can you expect, and what does PTP change?

Anywhere from tens of microseconds to tens of milliseconds, decided by your route rather than by the server you picked. NIST calls NTP the most commonly used Internet time protocol and the one that provides the best performance, then adds the line that matters most: accuracy as seen by a user will usually be determined largely by the stability and reciprocity of the network connection between the server and the user's systems. Reciprocity is path symmetry. The reference clock is not your limiting factor. Your ISP is.

The last row differs in kind, not degree. IEEE 1588-2019, the Precision Time Protocol, states in its scope that the protocol supports synchronization accuracy and precision in the sub-microsecond range, and it gets there by timestamping packets in NIC hardware on a controlled local network, with a grandmaster clock, usually GNSS-disciplined, in the same facility. You cannot buy PTP accuracy over the public internet at any price.

Microsoft documents that you can achieve down to one-millisecond time accuracy in a Windows domain, and gates that on a published support boundary: a close, low-latency time source, a shallow sync hierarchy, and machines that are not CPU-saturated, the virtualization host included. Confirm the current thresholds for your Windows version before relying on any of them. The principle outlives the numbers: anything that introduces path asymmetry, a satellite link or a pegged CPU included, degrades accuracy. CPU load causes clock error, not just latency.

What does a fixed offset do to a latency measurement?

It shifts every reading by exactly the offset, in exactly one direction, forever. Hold true one-way transit constant and vary only your clock.

Row one: you stamp send at your 14:30:00.100, which is 14:30:00.060 on the venue's scale, the venue stamps receipt 40 ms later at 14:30:00.100, and you subtract to get zero. A genuinely 40 ms pipeline reads as instantaneous. Row two doubles it, 0.140 - 0.060 = 0.080. Row three is the one people file as a bug, 0.025 - 0.040 = -0.015.

More samples never fix a bias. They just measure the same wrong number more precisely.

There is an escape hatch most traders never use. An interval measured entirely on one clock is immune to that clock's offset, because the same constant sits in both stamps and subtracts out. Stamp send at local 14:30:00.100 and fill-ack at local 14:30:00.185 and your 85 ms is correct no matter how wrong your absolute time is. Only frequency error survives: at 15 ppm, 0.085 x 0.000015 = 1.275 microseconds, and at a loose 50 ppm, 4.25 microseconds. Measure durations on one clock and use cross-machine stamps only for ordering and for absolute-time evidence.

Why is a copier's stage latency the hardest thing to measure?

Because every stage boundary is a cross-clock comparison by construction, so the escape hatch above is unavailable. A copier's end-to-end latency budget runs leader fill, copier ingest, copier decision, follower submit, follower fill, and those stages live on different machines with different clocks.

Take three machines and one order crossing both boundaries, with true time t. The trader PC clock reads t + 40 ms, the copier server reads t exactly, the follower broker reads t + 25 ms. Stage A is PC send to copier ingest, true duration 8 ms: the PC stamps t + 40, the copier stamps t + 8, so reported Stage A = 8 - 40 = minus 32 ms. Stage B is copier submit to broker ack, true duration 30 ms: the copier stamps u, the broker stamps u + 30 + 25 = u + 55, so reported Stage B = 55 ms. True total is 8 + 30 = 38 ms. Reported total is -32 + 55 = 23 ms.

The error on the total telescopes to broker offset minus PC offset, 25 - 40 = minus 15 ms, and 38 - 15 = 23 confirms it. That 15 ms is easy to shrug at; the per-stage numbers are not. Stage A is wrong by 40 ms and reads negative, Stage B is wrong by 25 ms and reads nearly double its true duration. You would spend a week optimizing the stage that was already fast. Be sceptical of any vendor latency claim, a copier's included, that does not say which clock produced the stamps.

How do you verify the clock on your own VPS?

Run the diagnostic and read the offset, because "the time service is running" and "the clock is disciplined" are different claims and only the second matters.

Microsoft documents a stand-alone Windows default of one NTP server, time.windows.com, with SpecialPollInterval set to 604,800 seconds. That is exactly 7 x 86,400: one poll per week against a single source. Domain members default to 3,600 seconds, and the Group Policy template ships a third default again at 1,024 seconds, so never assume which one applies: run w32tm /query /configuration and read what your box actually does. A full week of free-running drift would reach 604,800 x 0.000015 = 9.072 seconds at 15 ppm, or 30.24 seconds at 50 ppm. Frequency correction keeps a healthy machine far tighter, but a weekly check-in against a single source is a thin margin for a box that sends orders.

Commands worth knowing. w32tm /query /status reports stratum, root dispersion, poll interval, phase offset and time since last good sync; w32tm /stripchart /computer:<target> charts the offset against another computer without changing anything locally. On Linux, timedatectl status says whether the clock is synchronized at all, chronyc tracking gives the current offset and reference source, and chronyc sources -v shows which servers are actually in use.

Two documented behaviours explain log weirdness people blame on their software. Windows MaxAllowedPhaseOffset decides how a correction is applied: at or below it the clock is slewed through the clock rate, above it the clock is set immediately. The registry default is 1 second on stand-alone clients and servers and 300 seconds on domain members, with the Group Policy default at 300. An immediate set is a visible discontinuity, and it is how two events land out of order inside one log file on one machine. Virtual machines make those jumps likelier, because hypervisor pauses, live migrations and snapshot restores can strand a guest clock arbitrarily far from real time, one more reason a properly provisioned trading VPS with CPU headroom beats an oversubscribed one.

What should you log so your timeline counts as evidence?

Three fields per event, not one. A local monotonic counter for interval maths, because wall-clock time can step backwards when a correction lands, and an interval taken from two wall-clock reads can come out negative on the machine that just fixed itself. Local wall-clock time in UTC at millisecond precision or better, for identifying when. And the venue-reported timestamp verbatim, unparsed, because your conversion is lossy and the original string is the only thing the counterparty will recognise.

Regulated firms are held to documented clock discipline and you are not. FINRA Rule 4590 requires member business clocks to be synchronized to a source within a one second tolerance of the NIST atomic clock, tightened to a 50-millisecond tolerance for computer system clocks used to record events in NMS securities, including standardized options, and OTC Equity Securities, with synchronization every business day before market open and re-checks through the day. That binds FINRA members in the US securities markets the rule covers, not futures traders and not prop firms, so read it as a benchmark for what a defensible timestamp looks like, not a rule you are under. The asymmetry is the point: if their stamps are held to an audited tolerance and yours to nothing, your log is an assertion.

The federal futures floor is coarser and narrower than people assume. CFTC Regulation 1.35 requires a futures commission merchant, retail foreign exchange dealer, introducing broker or exchange member receiving a customer order that cannot immediately be entered into a trade matching engine to record the date and time the order is received to the nearest minute, and for commodity option orders the time it is transmitted for execution, also to the nearest minute. That governs their records, not your terminal, and exchange audit trail rules are stricter than the federal floor, so check the current CME rulebook for the precision your venue demands before quoting a figure.

Prop firm disputes are decided on a timeline: daily loss limits, trailing drawdown, news windows and consistency rules all reduce to when something happened. If a firm says a trade landed inside a restricted window and your log says otherwise, the argument is about whose clock is right, and the firm will cite server-side stamps while you cite your terminal's local ones. Saving chronyc tracking or w32tm /query /status output alongside your trade log costs nothing and turns your timeline into a measurement with a stated error bound. Expect the same fight when arguing execution slippage. Treat the venue stamp as the better record but not a complete one: the exchange stamps at its own gateway with its own disciplined clock, authoritative for what the venue did and useless as a measure of the network leg you experienced.

Why should every log line be in UTC?

Because local time repeats an hour twice a year and shifts on dates your counterparty does not share. On the fall-back night the local clock runs to 01:59:59 and restarts at 01:00:00, so a local-time log holds two rows stamped 01:30:00 that are 3,600 seconds apart with nothing to tell them apart. No parser recovers that ordering, and Sunday evening CME session opens sit inside those switch weekends.

Transition dates also differ by region. US daylight saving runs from 2:00 a.m. local on the second Sunday of March to 2:00 a.m. local on the first Sunday of November under 15 U.S.C. 260a, while EU summer time runs from the last Sunday in March to the last Sunday in October, both at 1:00 a.m. GMT under Directive 2000/84/EC, which remains the operative EU rule as of this writing because the 2018 proposal to end seasonal changes was not adopted. In 2026 that puts the US changes on 8 March and 1 November and the EU changes on 29 March and 25 October, leaving two windows (8 to 29 March, 21 days, and 25 October to 1 November, 7 days) where a US-local log sits one hour further from a European broker's log than usual. Twenty-eight days a year of silent one-hour error, removed entirely by logging UTC.

Platform APIs encode the same distinction. MQL5 documents MetaTrader's TimeCurrent as the last known server time, a value formed on the trade server that does not depend on the time settings on your computer, while TimeGMT is calculated from your machine's own local time and daylight-saving settings and is therefore only as correct as your own clock. An expert advisor that subtracts one from the other is comparing two different clocks.

One edge case, and its expiry date. Google Public NTP absorbs leap seconds with a 24-hour linear smear running noon to noon UTC, during which smeared time sits just under half a second from standard UTC, first behind and then ahead. Several large providers smear; dedicated hardware time sources generally do not. Point two machines at one of each during a smear and they can differ by close to half a second, more than a dozen times the 40 ms offset above, while both report perfect health. The exposure is shrinking: no leap second has been inserted since the end of December 2016, and CGPM Resolution 4 of 2022 resolved that the maximum UT1 minus UTC difference will be increased in or before 2035.

When is clock discipline not worth your time?

When the quantity you argue about is much larger than your clock error. If you hold positions for hours and your edge lives on a one-minute chart, a 40 ms offset is irrelevant and chasing sub-millisecond synchronization is wasted effort. Verify NTP once, log in UTC, go back to trading. The goal was never perfection but a clock error that is bounded rather than unknown: a known 8 ms bound is usable evidence, while an unknown offset invalidates every timing conclusion you draw, including on the days it happens to be right.

Start caring when the disputed quantity is comparable to the plausible error: a fill argued over a few hundred milliseconds, a copier slippage claim, a latency optimization measured in tens of milliseconds. And here is the uncomfortable part for anyone selling in this category. A trade copier cannot fix an undisciplined clock, and buying a faster one to settle a timestamp disagreement solves the wrong problem. If your logs disagree with your broker, check your clock first. The copier is the second suspect.

Frequently asked questions