Earnings Calendar Data: Dates, Timing, and Revisions
Why a date on today’s calendar is not enough to reconstruct what investors knew before an earnings report.
Earnings calendar data records when companies are expected to report and when they actually report. Reliable history preserves company and fiscal period, scheduled date and time, before/after/unknown session, confirmation or estimate status, every observed schedule revision, source, observation time, actual event time, and the cutoff used to answer an as-of query.
Schedules are versioned facts
Companies can confirm, move, or clarify earnings dates. Aggregators also publish estimates before issuer confirmation. Replacing the earlier estimate with the latest date destroys the history needed for alerts and backtests.
Store each observation with source, confidence, and known-at time. The actual report is a separate event, not a retroactive correction to every earlier schedule row.
Map the event to a tradable session
Before-market and after-market announcements imply different reaction windows. Unknown timing should remain unknown rather than guessed from the date.
Use exchange timezone, holidays, and early closes. An event after Friday’s close normally belongs to the next tradable session, not to Friday’s close.
- Preserve schedule revisions.
- Separate estimated, confirmed, and reported states.
- Use exchange sessions and timezone.
- Join by company identity and fiscal period.
Evaluate an earnings calendar API
Ask for future and historical coverage, revision history, source, timing confidence, fiscal periods, actual report times, pagination, corrections, and coverage states. A future-only calendar is not historical research data.
DataCedar exposes effective and known-at clocks so a query can reconstruct the calendar visible at a prior decision time.
How DataCedar preserves the evidence
DataCedar separates acquisition from serving. Permitted source responses are retained with retrieval time and identifiers, normalized into DataCedar-owned tables, checked against expected coverage, and exposed through a stable versioned API. A collector can be replaced without changing the customer contract or making an upstream provider a runtime dependency.
Every research stream carries effective and known-at time where the distinction matters. Rights-restricted, unavailable, partial, stale, and genuinely empty states remain visible, so a backtest can fail closed and a buyer can see the product boundary before committing engineering time.
Key takeaways
- 01Do not overwrite old schedules.
- 02Keep date, session timing, and fiscal period together.
- 03Treat actual reporting as a separate event.
- 04Use as-of filtering for backtests.
Query public company evidence through one stable API. Free Explorer tier, no card.
Start freeView pricing