Reminder to be careful with timestamps when backtesting

[u/status-code-200]

Say you have a dataset. It says X event happened at time Y. There is a very good chance it did not happen at time Y.

This is due to:

1. Measurement error
2. The timestamp does not mean what you think it means

For example, say you are using the SEC Corpus. Claude and other LLMs will advise you to use acceptance datetime.

This is a bad idea.

Acceptance datetime is not when the filing has been released to the public. It actually may be days prior. For example, a filing accepted on a Friday, may be released to the public on Monday.

Also, the SEC misreports acceptance datetime on most of its endpoints. There is an issue where it assigns either the exact timestamp, +4, -4 or +5,-5 (depending on DST). The correct timestamp is found (generally) within the SEC filing's SGML file.

Additionally, SEC data is often published first via newswire. So, markets may have already reacted to the news.

This extrapolates to other datasets. One way to improve backtesting performance is to create features that assume that timestamp may not be quite correct. If this works, it is a sign that there may be something off with your datasets timestamps.

Links (can remove, not sure if falls afoul of self promotion):

• SEC filing detected time dataset: GitHub
• Bad timezone timestamps: GitHub

[u/DeskbotTrader]

good reminder. one I'd add: check whether your timestamps are bar-open or bar-close before trusting any edge — that alone has quietly inflated a few early backtests I've seen. also worth normalizing everything to one timezone before comparing against news or economic calendar events, mixing local and utc is an easy way to leak future data.

[u/yuravest]

The check I use after one strategy died on timestamps: for every entry, pull the raw tick inside the bar and ask whether the price I booked existed in the first second after the bar close. If it only showed up later, the backtest was reading the future.

For the event-driven stuff, log the dataset timestamp and the earliest timestamp a retail trader could have seen it. More than a few seconds apart and the feature is look-ahead by default.

[u/Maleficent-Success-6]

This is an important distinction, and I'd go one step further by treating event time and information availability time as separate fields.

For each external observation, I'd ideally preserve:

• The timestamp assigned by the source.
• The earliest verified publication timestamp.
• When the data provider made it available.
• When the trading engine actually received it.

Those timestamps can differ substantially.

For backtesting, the relevant question isn't simply when something happened. It's whether the strategy could actually have known about it before making its decision.

I'd also test uncertain timestamps conservatively rather than assuming the earliest possible availability.

One particularly useful validation would be replaying historical decisions using only records whose availability time precedes the decision timestamp.

If the edge disappears, that's important evidence about the data pipeline, not necessarily the strategy logic.

Do you maintain separate publication and ingestion timestamps in your datasets?

[u/QATSAlgo]

A timestamp regression test would be useful alongside the lag stress test: keep a small fixture of events around weekends and both DST transitions, with independently checked availability times. Then make the data importer fail if an update shifts those fixtures. Otherwise a vendor or parser change can quietly reintroduce the same leak after the research has been corrected.

[u/QuanTradin]

bar timestamps do the same thing quietly. some vendors stamp a 1-min bar at its open, some at its close, and mixing two sources hands the backtest a minute of the future without anyone noticing.