Timestamp Hygiene for Text-Derived Signals

A story breaks that a company missed earnings. The event happened at 4:01pm. The newswire published its first headline at 4:03pm. A slower secondary aggregator picked it up and re-published it, with the original event time stamped on it, at 4:11pm. If a backtest naively uses "event time" to decide when the signal was available, it effectively lets the strategy trade on information eight minutes before any real feed delivered it — a small, easy-to-miss error that can make a mediocre news strategy look consistently profitable in simulation and consistently mediocre in production.

Timestamp hygiene is the discipline of tracking, for every piece of text-derived data, the exact moment it was actually knowable to a trading system, and using only that timestamp to decide what a backtest is allowed to see.

Where the leakage creeps in

Several distinct timestamps exist for any single news item, and it's easy to accidentally pick the wrong one:

• Event time — when the underlying real-world thing happened (the earnings miss itself).
• First-publication time — when a specific feed first made the story available.
• Ingestion time — when your own pipeline received and parsed it, which lags publication by network and processing latency.
• Revision time — many providers correct or amend stories after the fact; a backtest that uses the final, corrected version of an article at its original timestamp is leaking future corrections into the past.

The only timestamp a backtest should ever key a decision on is ingestion time of the version of the text your system actually saw, not event time and not a later-cleaned version of the document.

Worked example

A vendor's news database stores each story with a single timestamp column, and a naive backtest joins signals to prices using that column directly. Investigating one flagged story: the vendor's timestamp reads 09:28:00, matching when Reuters first published it — but the backtest's price data is sampled at 1-minute bars starting from market open at 09:30, and the strategy's signal-generation code has a further 45-second processing lag before a feature is computed. If the backtest naively assumes the signal is "available" at 09:28:00 and trades the 09:29 bar, it is trading on a signal it would not have actually possessed until roughly 09:28:45 — usually harmless for a 45-second gap, but the exact same bug at a data vendor with a known 20-minute delayed-news tier, or on a story that was corrected six hours later and the correction silently overwrote the original row, can flip a two-week test from profitable to worthless once the vendor's own revision history is checked.

What this means in practice

Timestamp bugs are quiet: they don't crash a backtest, they just make it look better than reality, often by exactly the margin needed to make a marginal strategy look tradeable. Any pipeline that ingests third-party text data should log its own receipt time independently of whatever timestamp the vendor supplies, store every revision of a document rather than overwriting in place, and audit a sample of "great" trades by hand to confirm the signal really was computable at the time claimed.