When Historical Market Data Gets Revised

Historical market data gets revised more often than most backtests assume. A vendor repairs a gap, changes a timestamp convention, reassigns a ticker, or reprocesses a corporate action, and the archive on your disk stops matching today's download. This post sorts those revisions into four families, says what each one can change in a strategy result and what it leaves alone, and sets out the short record that keeps an old number checkable a year later.

The case: a winter bug that dropped after-hours rows

Start with a defect of a shape that turns up in dataset change notices. An intraday dataset converts exchange time to UTC with a fixed offset instead of a real time zone. Through the summer the offset matches. Through the winter months it is wrong by an hour, and the hour it drops sits at the end of the extended session. Rows that printed on the tape were never written into the dataset, on winter dates, across the dataset's entire history.

Two properties of that defect keep it hidden. The missing rows sit outside the regular session, where a thin chart looks normal anyway. And every row that is present is accurate, so a row-level validator finds nothing wrong. The defect lives in the rows that are absent, which is the hardest thing for a data check to see. Our walk-through of how OHLCV bars are built covers the aggregation step where a missing minute vanishes into a wider bar without leaving a mark.

The first panel measures the exposure: where a trading day's volume actually sits, hour by hour.

WITH tape AS
(
    SELECT
        toTimeZone(window_start, 'America/New_York') AS et,
        volume
    FROM global_markets.delayed_stocks_minute_aggs
    WHERE ticker = 'AAPL'
      AND window_start >= '2026-01-01 05:00:00'
      AND window_start <  '2026-02-01 05:00:00'
)
SELECT
    formatDateTime(et, '%H:00')                                  AS et_hour,
    count()                                                      AS minute_bars,
    round(100 * sum(volume) / (SELECT sum(volume) FROM tape), 2) AS pct_of_shares
FROM tape
GROUP BY et_hour
ORDER BY et_hour

Across January 2026, AAPL minute bars fall into 16 distinct Eastern clock hours. The earliest hour the tape carries, the 4 a.m. ET hour, holds 0.11% of the month's shares while printing a near-full complement of one-minute rows. That asymmetry is the trap. Extended-hours activity is a small fraction of shares and a large fraction of rows, so a bug that removes those rows barely moves a volume total and badly damages anything counted per bar.

A seasonal defect has a signature, and the way to look for one is to measure the same statistic month by month. A dataset quietly losing an hour of the late session through the winter prints a step down in November and a step back up in March.

WITH tape AS
(
    SELECT
        toStartOfMonth(toTimeZone(window_start, 'America/New_York')) AS m,
        toHour(toTimeZone(window_start, 'America/New_York')) * 60
            + toMinute(toTimeZone(window_start, 'America/New_York')) AS et_minute,
        volume
    FROM global_markets.delayed_stocks_minute_aggs
    WHERE ticker = 'AAPL'
      AND window_start >= '2024-10-01 04:00:00'
      AND window_start <  '2026-10-01 04:00:00'
)
SELECT
    toString(m)                                                                    AS month,
    formatDateTime(m, '%b %Y')                                                     AS month_label,
    round(100 * sumIf(volume, et_minute < 570 OR et_minute >= 960) / sum(volume), 2) AS outside_rth_volume_pct,
    round(100 * countIf(et_minute < 570 OR et_minute >= 960) / count(), 2)           AS outside_rth_bars_pct
FROM tape
GROUP BY m, month_label
ORDER BY m

Measured on AAPL over the two years to September 2026, the outside-session share of volume ran 9.13% in Oct 2024 and 6.38% in Sep 2026. The row share is the far larger number: 54.01% of that final month's minute bars fell outside 9:30 a.m. to 4:00 p.m. ET. A flat series like this one is what a repaired dataset looks like. A broken one carries a November notch in both columns, repeating every year.

One caveat about this case, and it is the method of the post rather than an aside. Nothing above names a vendor, a dataset or a notice date. Vendor-specific claims age badly: the fix ships, the notice is superseded, and a page that asserted the broken behaviour as a standing fact is then simply wrong. When you write a defect into your own notes, pin it to the dated change notice you read it in, with the notice identifier and the dataset version it covers, and date the sentence yourself. A later reader can then work out what has since changed. The mechanics below hold. An inventory of live defects does not.

A fix is itself a breaking change

When the vendor repairs that conversion and backfills, the whole history of the dataset changes. Winter-date volume totals rise. The last print of the day moves later in the session. Any statistic normalised by session volume or counted per bar shifts. A number computed on last year's extract and the same number computed today disagree, and neither is a mistake. They are two datasets sharing one name.

That is the part worth holding onto. A correction is not a continuation of the series you had, it is a new version of it. Give a vendor fix the ceremony of a schema migration: re-run the prior result, store the old and new figures side by side, and record which dataset version produced each.

Four ways historical market data gets revised

Revisions sort into four families. The useful question for each one is narrow. Which results can it flip, and which does it leave untouched?

Gap repair and backfill

Missing rows arrive, or bad rows are withdrawn. It can flip anything counted per observation, anything averaged over a window that now holds more observations, and any gap-detection logic calibrated on the old holes. It leaves a daily close-to-close series alone, as long as the repair was intraday. Backfill carries a subtler hazard too. Rows delivered later than the timestamps they carry sit in your history at a moment when nobody could have seen them, which is the mechanism behind look-ahead bias in backtesting.

Timestamp and snapshot convention changes

A vendor moves from exchange-local time to UTC, or from bar-open to bar-close labelling, or shifts a daily snapshot from the closing print to a settlement cutoff. Every value is unchanged. Every value now sits at a different index. It can flip event studies, any join of two sources on a timestamp, and intraday rules anchored to a clock. It leaves distribution statistics over a long window alone. The panel below shows why a fixed offset fails: it walks the sessions around the November 2025 clock change and prints, for each, the UTC and Eastern stamp of that session's first bar.

SELECT
    toString(toDate(toTimeZone(window_start, 'America/New_York')))                 AS session_date,
    formatDateTime(toDate(toTimeZone(window_start, 'America/New_York')), '%b %e')  AS session_label,
    formatDateTime(min(window_start), '%H:%i')                                     AS first_bar_utc,
    formatDateTime(toTimeZone(min(window_start), 'America/New_York'), '%H:%i')     AS first_bar_et,
    toInt16(toHour(toTimeZone(min(window_start), 'America/New_York')))
        - toInt16(toHour(min(window_start)))                                       AS et_utc_offset_hours
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker = 'AAPL'
  AND window_start >= '2025-10-27 04:00:00'
  AND window_start <  '2025-11-08 05:00:00'
GROUP BY session_date, session_label
ORDER BY session_date

The offset column reads -4 on Oct 27 and -5 on Nov 7, with the step between them landing on the first Sunday in November. A query that hardcodes a UTC window for the session loses an hour on one side of that step, every year, in both directions over a long history. Group by Eastern clock time and the question never arises. Market data timestamps covers the conventions in full.

Identifier reassignment

A ticker is a lease, not a name. A delisted symbol returns to the exchange and can be handed to an unrelated issuer, and most datasets key on the symbol. It can flip any ticker-keyed join, any sector mapping, and any long history stitched together by symbol. Survivorship bias work is the most exposed of all, since the dead names are the whole point of the exercise. It leaves single-name research conducted entirely inside one entity's listing window alone. The IPO record shows how often a symbol changes hands.

WITH symbol_issuers AS
(
    SELECT
        ticker,
        issuer_name,
        min(listing_date) AS first_listing
    FROM global_markets.stocks_ipos
    WHERE listing_date >= '2010-01-01'
      AND listing_date <  '2026-10-01'
      AND ticker != ''
      AND ticker NOT IN ('SPCX')
    GROUP BY ticker, issuer_name
),
reused AS
(
    SELECT
        ticker,
        count()            AS issuer_count,
        max(first_listing) AS latest_listing
    FROM symbol_issuers
    GROUP BY ticker
    HAVING issuer_count > 1
)
SELECT
    toString(toYear(latest_listing)) AS listing_year,
    count()                          AS symbols_reassigned,
    round(avg(issuer_count), 2)      AS issuers_per_symbol
FROM reused
GROUP BY listing_year
ORDER BY listing_year

9 listing years since 2010 contain at least one symbol that a second issuer went on to carry. The most recent year in the panel, 2026, holds 22 of them, averaging 2.09 issuers per symbol. Key on a permanent identifier, carry the listing window alongside it, and read why ticker symbols break datasets for the join patterns that survive this.

Corporate-action reprocessing

Adjustment factors get recomputed, a special distribution is reclassified, a split is applied across a longer history than before. The entire price level moves. It can flip every level-sensitive rule: a moving-average crossover, a stop distance quoted in dollars, a dollar-volume liquidity filter. It leaves a return series computed from properly adjusted prices alone, which is invariant to the adjustment basis. Corporate actions arrive continuously, so the reprocessing is continuous as well.

SELECT
    toString(toStartOfMonth(execution_date))                              AS month,
    formatDateTime(toStartOfMonth(execution_date), '%b %Y')               AS month_label,
    countDistinct(id)                                                     AS splits_executed,
    countDistinctIf(id, toFloat64(split_to) / toFloat64(split_from) < 1)  AS reverse_splits
FROM global_markets.stocks_splits
WHERE execution_date >= '2024-10-01'
  AND execution_date <  '2026-10-01'
GROUP BY month, month_label
ORDER BY month

165 splits took effect in Sep 2026, 107 of them reverse splits, and the two-year series shows the cadence holding month after month. Each entry rewrites the adjusted history of one symbol for every date before its execution date. Split-adjusted price history works through a single name in detail.

How to record a result so it stays checkable

Reproducibility here is a bookkeeping problem rather than a research problem. Keep the following next to every published number, in the same file as the number:

• The vendor and the dataset name, at the granularity the vendor versions.
• The venue or feed the extract covers, and whether it is consolidated or single-venue.
• The schema or dataset version string the vendor publishes, copied verbatim.
• The retrieval timestamp in UTC, kept separate from the date range of the data itself.
• A checksum of the extract you actually loaded: sha256sum over the file, stored with the result.
• The row count and the exact first and last timestamp the extract spans.
• The query or API call, verbatim.

The checksum is the field that does the real work. A version string tells you what the vendor intended to ship. A hash of your file tells you what you read, and it catches a silent re-issue under an unchanged version label.

Then one habit on top of the log. After any vendor update, re-run the prior result instead of assuming continuity. If the number holds, you have evidence. If it moves, you know the size of the move before anyone asks, and you have a dated pair of figures to explain it with.

FAQ

Does historical market data change after it is published?

Yes, routinely. Vendors backfill missing rows, correct time conversions, re-run corporate-action adjustments and re-key identifiers, and most of those changes apply to the whole history rather than only the front edge. An archive downloaded a year ago is a specific version of the data, not the data.

How do I tell whether a vendor has revised a dataset?

Compare rather than assume. Keep a checksum and a row count for each extract, re-pull a fixed historical window on a schedule, and diff it against what you stored. Release notes and dataset version strings are the first signal. Your own diff is the one that is checkable.

Which backtests are most sensitive to a data revision?

Anything counted per observation or anchored to a clock: intraday rules, event studies around a timestamp, per-bar statistics, dollar-level filters. Return-based studies over long windows are the most robust, since adjustment changes largely cancel out in returns.

Do I need to rerun an old backtest after a correction?

Rerunning is the only way to know what moved. A workable bar: re-run any result you still cite publicly, store the new figure alongside the old one with both dataset versions named, and keep the old extract rather than overwriting it.

Every panel here carries the SQL that produced it in an expander underneath. To measure the outside-session share of a symbol across a particular month, or to count how often a ticker has changed hands, ask the question in plain English on the Strasmore terminal.