Timestamp Reconciliation Kit

Two logs of "the same" events - a broker's server-side fill log against a locally recorded one, two market data feeds, a strategy tester run against its live counterpart - rarely share an identical clock. Before anything downstream can compare them record-for-record, the records need matching up despite a timestamp offset, and that offset itself is diagnostic information worth extracting, not just noise to work around. TrkMatchByTolerance performs a greedy nearest-neighbour match: both series are assumed already time-sorted, and for each source-A record in order it takes the nearest not-yet-used source-B record within the tolerance window. A full bipartite assignment solver would find a marginally better global pairing in pathological cases, but is overkill here - a genuine clock skew is roughly constant across a session, so nearest-candidate matching in time order is correct in practice, and the search floor only ever advances (never re-scans discarded B records), keeping the whole match close to linear in the combined record count. TrkEstimateSkewSeconds takes the MEDIAN of the matched pairs' offsets rather than the mean, for the same robustness reason used throughout this catalogue's statistics libraries: a handful of mismatched pairs near the tolerance boundary pull a mean far more than they pull a median. TrkEstimateDriftRate goes a step further and fits an ordinary-least- -squares slope of offset against elapsed time - a clock that is not just offset but genuinely running fast or slow shows up as a nonzero slope in seconds of extra drift per second elapsed, distinct from the constant skew TrkEstimateSkewSeconds reports. Notes and limitations - Both input series must already be sorted ascending by timestamp - the search-floor optimisation inside TrkMatchByTolerance assumes it and will silently under-match (not crash) against an unsorted series. - A tolerance window that is too wide relative to the record spacing can let two genuinely different events pair up; a tolerance too narrow under-matches a series carrying real drift. Widen the tolerance and compare the matched count against the smaller series' total count if the estimate looks unstable. - TrkEstimateDriftRate needs at least 2 matched pairs to fit a slope and returns 0.0 below that - treat a small matched count's drift estimate as low-confidence regardless of the returned number. - This kit answers "how are these two clocks related", not "which record in A corresponds to which record in B for a downstream join" beyond the index pairing TrkMatchByTolerance already returns - a caller wanting to merge additional payload fields uses matchA[]/matchB[] as the join key.

Script · MT5 · v1.0 · Free

Tags: MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria