Point-in-time data

Point-in-time stock data for backtests without look-ahead bias

Apply one as-of cutoff across filings, XBRL facts, earnings schedules, stock-news links, macro observations, and permitted market history. Later amendments and corrections remain separate versions instead of overwriting earlier inputs.

Start free Read the API docs
Effective
what the record describes
Known-at
when it became usable
Versioned
corrections and amendments
Covered
availability state
Definition

Point-in-time data stores at least two clocks: effective time describes the period or event, while known-at time describes when the record was available to the system. An as-of query returns the version visible before a chosen cutoff.

How DataCedar handles it

What you can query, which fields are returned, and how availability is reported.

01

Keep multiple clocks

Period end, event time, publication, database retrieval, market session, and correction time remain distinct fields.

02

Append revisions

Later amendments and corrected values become new records with lineage rather than mutating the earlier research input.

03

Filter every joined stream

An as-of cutoff applies to filings, facts, schedules, news references, macro observations, and any permitted market history in the dataset.

04

Expose incomplete history

Collection start, source gaps, ingestion failures, and rights restrictions are explicit coverage states, not invisible absences.

Data surface

What the schema is built to carry.

Effective and known-at timestamps
As-of query filters
Revision and amendment lineage
Immutable raw-object references
Coverage-state ledger
Ingestion run provenance
Security identity history
Reproducible event snapshots

Product boundary: Point-in-time modelling does not make a dataset magically complete. Quality still depends on the source's historical depth and when collection began, so DataCedar reports temporal coverage per stream.

API example

As-of event reconstruction

GET /v3/stocks/{symbol}/events?as_of=...
Request
curl "https://api.datacedar.com/v3/stocks/AAPL/events?as_of=2025-02-01T00:00:00Z&limit=100" \
  -H "X-API-Key: $QUARTERTRACE_API_KEY"
Representative response
{
  "data": [{
    "event_type": "earnings_schedule",
    "effective_at": "2025-02-27T21:00:00Z",
    "known_at": "2025-01-20T14:12:00Z",
    "version": 2,
    "supersedes": "event_version_1"
  }],
  "as_of": "2025-02-01T00:00:00Z"
}

Examples document the public contract and may use illustrative values or redacted identifiers. Availability fields and rights filters are authoritative for the active environment.

Research workflow

Four steps from API key to a validated dataset.

01

Define

Choose the exact simulated decision timestamp and timezone.

02

Filter

Select only records whose known-at time is at or before that cutoff.

03

Resolve

For each effective item, use the latest eligible version without deleting older versions.

04

Audit

Save the coverage snapshot, source runs, and schema version with the experiment.

Field guide

Point-in-time data and the mechanics of look-ahead bias

01

One date column cannot answer two questions

A revenue value can describe a quarter ending in March, appear in a filing in May, enter a database minutes later, and be amended months afterward. Each timestamp answers a different question.

DataCedar keeps the economic or effective time separate from publication, retrieval, and known-at time. Backtests filter by availability and then analyze by the period the fact describes.

  • Never substitute period end for publication time.
  • Define timezone and market-session rules.
  • Keep late-arriving records visible.
02

Latest-value databases rewrite the past

Many convenient APIs return the cleanest value known today. That is useful for current analysis but can leak restatements, schedule confirmations, corrected macro releases, and revised identifiers into historical training data.

DataCedar appends versions and records which observation supersedes another. An as-of query resolves only among versions that were actually knowable before the cutoff.

  • Store revisions as rows, not in-place updates.
  • Version mappings as well as values.
  • Test the same query at cutoffs before and after a revision.
03

Point in time is not the same as survivorship-bias free

Known-at timestamps prevent future information leakage, while survivorship-bias controls require a historical security universe that includes names that later delisted or changed. A dataset can solve one problem and still fail the other.

DataCedar's security model retains issuer and symbol history, but actual delisted-market coverage depends on a permitted source. Coverage metadata makes that limitation visible rather than claiming a perfect universe.

  • Build the universe as of the simulated date.
  • Retain inactive and renamed securities.
  • Document source-history start dates.
Comparison

Latest data versus point-in-time data

The latest table is cleaner. The point-in-time table is the one a historical strategy could have used.

CorrectionsReplace the prior valueAppend a linked version
Earnings datesFinal date shown historicallySchedule visible at the cutoff
FundamentalsLatest restated factEligible filing version only
CoverageAbsence appears emptyMissing, delayed, unavailable, or restricted
ReproductionDepends on today's databaseAs-of cutoff plus source snapshot
Before you rely on it

A practical validation checklist.

  1. 01The decision timestamp and timezone are explicit
  2. 02Every stream has an availability timestamp
  3. 03Revisions append instead of overwrite
  4. 04The eligible version is resolved after applying the cutoff
  5. 05Universe membership is historical, not today's list
  6. 06Coverage start and gaps are documented
  7. 07The as-of query is saved with the model artifact

Questions, answered.

Look-ahead bias occurs when a historical test uses information that was not available at the simulated decision time, such as a later restatement or finalized schedule.

Continue the research

Historical stock data →

Build historical stock price and volume exports with explicit adjustments, coverage checks, symbol history, and event windows for reproducible backtesting.

Stock market data API →

Query permitted stock price and volume beside SEC filings, earnings events, point-in-time fundamentals, news references, macro data, and coverage metadata.

SEC filings API →

Query SEC filing metadata, primary documents, exhibits, XBRL facts, and amendments with accession-level provenance and known-at timestamps.

Earnings calendar API →

Query scheduled, confirmed, rescheduled, and completed earnings events with known-at history, source evidence, fiscal periods, and reaction windows.

Create a free API key for filings, facts, earnings events, news links, and macro data.

Explorer is $0 with no card and a 1 request/second limit. Market history and transcript text appear only when an eligible source is active for the account.

Open DataCedar