Every financial data point carries two dates, and most datasets only store one of them.
The effective date is the period the number describes. The publication date is when the number became public. A company’s September quarter results have an effective date of 30 September and a publication date somewhere in November. A dataset that stores only the first will let a backtest trade on results weeks before they existed.
Point-in-time data keeps both, so a query can ask what was known on a given day rather than what is true about a given day.
The two dates in practice
| Data type | Effective date | Typically published |
|---|---|---|
| Quarterly results | Quarter end | Up to 45 days later, per SEBI LODR Regulation 33 |
| Annual results | Financial year end | Up to 60 days later |
| Index reconstitution | Effective date of the change | Announced in advance, applied on the effective date |
| Macro series such as CPI or IIP | The month described | Released the following month |
| Shareholding pattern | Quarter end | Filed after quarter end |
The gap is not a rounding error. For a strategy that rebalances monthly on fundamentals, a 45-day publication lag means one or two rebalances are made on data the market did not have.
Restatements are the second problem
A company can revise a previously filed number. A vendor database usually overwrites the old value with the corrected one, which means the history you query today is not the history anyone traded on. Point-in-time storage keeps the original vintage alongside the revision, so a backtest sees the figure as first reported.
Caveats
Point-in-time correctness is a property of the pipeline, not of any single rule, so it cannot be fixed at the strategy layer. If the underlying store has already overwritten history, no amount of careful rule design recovers it.
The practical test is simple. Pick a rebalance date from three years ago, look at what your strategy selected, and ask whether every input it used was public that morning. If you cannot answer that from the data itself, treat the backtest as an upper bound rather than an estimate.