Start with two dates, then add a retrieval time
A chart downloaded today can describe an old month using information that did not exist in that month. Saving the observation date alone therefore cannot establish what a historical decision could have used. Your research record needs the period being measured, the version of the data and the moment you obtained that version.
FRED's real-time-period documentation distinguishes today's available information from information available in a historical period. Its realtime_start and realtime_end parameters use dates with inclusive boundaries. These are data-version controls; a date-level response does not, by itself, establish the exact second at which a market participant could receive a release.
For a US release study, retain the original release notice and its stated time zone separately from the downloaded series. A New York calendar entry, a UTC retrieval timestamp and the data's monthly observation label answer different questions. Do not convert a monthly label into a fictional publication timestamp.
A fictional revision changes an input, not the old record
Suppose an invented monthly series DEMO-US-X reports January as 100 in a version available on February 15, then reports that same January observation as 98 in a March 15 version. These numbers and dates are teaching inputs, not observations from a real economic series. The observation key remains January; the information version changes.
A study with a February 20 decision cutoff can retain the February version as its candidate input, subject to checking the actual release and availability evidence. The March value belongs in a later-version comparison. Replacing 100 with 98 in the original input file would erase the very difference the audit is meant to preserve.
Keep both rows and calculate a separate revision field: later value minus earlier value equals -2 in this example. That difference is neither a trading return nor proof that the earlier publisher made an error. It simply records a change between two supplied versions.
| Observation | Version date | Entered value | Role in the example |
|---|---|---|---|
| January, DEMO-US-X | 2026-02-15 | 100 | Earlier candidate input |
| January, DEMO-US-X | 2026-03-15 | 98 | Later comparison, kept separately |
The evidence table to keep with your research
Use one row per observation and version. Preserve the series identifier, original observation label, units, seasonal-adjustment description, real-time parameters, value, retrieval timestamp and a reference to the saved response. Keep the source release link in a separate column. An empty value remains missing; it should not become zero merely to make a calculation run.
Store each retrieved file as a new version rather than saving over the previous file. A local checksum can help detect later changes to your saved bytes. It does not prove historical publication, independent custody or a trustworthy timestamp. If you have only a current download, label the earlier version unavailable instead of recreating it from memory.
When two files disagree, first compare series IDs, units and transformations. A percent-change series and an index-level series are not competing vintages of the same input. Keep revisions, unit changes and your own transformations as separate fields so a reviewer can reproduce the comparison.
Stop at the limit of your availability evidence
The vintage-dates endpoint describes dates on which a series gained new or revised values; its list excludes release dates with no change in the series' values. Consequently, an absent vintage date is not evidence that no announcement happened that day. Use the original publisher's release calendar when that is the question.
For an intraday cutoff, a date-level vintage is insufficient when release ordering within that day matters. Mark the availability decision unresolved until the required timestamp evidence is available. This preserves the difference between a sensible research convention and an independently demonstrated information set.
Finish with two outputs: the preserved historical-input table and a later-revision comparison. Neither evaluates a signal provider, proves predictive skill or recommends a position. The optional offer link below leads to this site's separate crypto signals and Telegram updates landing page; using that offer is not required to keep this research record.
Primary sources and scope
- FRED API: Real-Time Periods
Historical information versions, real-time parameters and inclusive date boundaries; not intraday availability. Checked 2026-10-21. - FRED API: Series Vintage Dates
Vintage dates identify new or changed values and omit release dates with no series-value change. Checked 2026-10-21.