What is point-in-time data? Understanding historical availability
Distinguish observation dates, publication times and revisions, and understand why frozen data is not necessarily point-in-time data.
Use the information version available at the historical decision
Point-in-time data, or PIT data, lets a researcher select the version of information available at a historical decision time. It does not merely mean access to a long historical series. The key question is whether a history downloaded today matches the information available then.
Trace publication times, revision times and saved versions as well as the dates that prices or financial figures describe. These distinctions underpin the avoidance of lookahead bias. Combining every timestamp into a single “date” column can hide those relationships.
A reporting period differs from a publication time
A financial figure describing a period ending in March was not necessarily published at the end of March. Joining later-publicized information as though it were usable from the period end inserts unpublished information into historical decisions. The reporting period answers what was measured; publication timing answers when it could be known.
The researcher's download date has another meaning. It proves acquisition, not which version market participants could see years earlier. A date without a time also leaves intraday availability unknown. Do not add timestamp precision that the source does not establish merely for processing convenience.
Separate initial releases from revised values
In an artificial example, a fictional company first publishes a value of 100 on May 10, then revises it to 105 on June 20. This is not an actual company's reporting history. A decision at the end of May must use the initial value of 100 if that was the available version, rather than the later revision.
For decisions after June 20, the revised version can be used once its availability time has been checked. Overwriting the initial value with the latest number removes the ability to reconstruct the historical information state. Store the reporting period separately from the times when each version became available.
Frozen inputs support reproducibility
Freezing data preserves selected rows and file identities so later changes do not silently alter a calculation. It helps establish that the same input was used. Freezing a currently available revised history, however, does not turn it into the historical information version.
The public KabuForge course shows how to check input identities and execution records. Its reference runs explicitly declare pit_guarantee=false and do not guarantee historical availability. Keep input-freeze verification separate from PIT verification, with evidence for each.
What to check in existing local data
Even when you already hold lawfully acquired local J-Quants data that you are permitted to use, check field meanings, price conventions, publication timing and revision handling. Match source and preservation records rather than judging availability from the download date alone. This discussion does not certify current API specifications, pricing or licence terms.
Record the source, acquisition time, covered period, data version, selection conditions, input identity and known limitations. Missing timing evidence remains a research limitation. Continue to local J-Quants setup and price-data checks to inspect inputs.
Public sources and research limitations
The workflow and display sources are the public GUI research course and public evidence summary. Reviewed October 6, 2026. The images record a GUI run from public-candidate source; they do not establish installed-distribution acceptance.
Reference results are research-only, with historical information availability unverified. Do not infer future profits from teaching examples or reference results; check their assumptions and limitations. Read the disclaimer.
Continue this topic
Applies to: main source candidate (unpublished) · Public source docs/en_US/GUI_RESEARCH_COURSES.md
Reviewed · KabuForge