I prototype scrapers for personal research. I do not bet size on a CSS selector that can vanish on a Thursday. Learned that when a "confirmed" time silently flipped and I still had working orders like an idiot.
### Practical approach
1. Prefer **official IR pages** + licensed calendar APIs for anything you size on.
2. If you prototype scrapers: throttle hard, cache aggressively, expect HTML to change the week you need it.
3. Store: ticker, period, date, bmo/amc flag, confirmed vs estimated, source URL, retrieved_at.
### Schema worth keeping
Code: Select all
ticker,period,date_et,session_flag,status,eps_est,rev_est,source_url,retrieved_at_et
Code: Select all
[ ] User-Agent honest / not pretending to be Googlebot
[ ] 1 request / N seconds
[ ] Parse fails → alert, don't silently trade empty calendar
[ ] DST / ET conversion tested around spring/fall
[ ] Confirmed vs expected labeled in UI
Earnings week ≠ "fade everything." It means: know **who reports tonight**, cut size into binary events, and don't leave working orders through prints you didn't plan for.
Not posting site-specific selectors on purpose — they rot and encourage reckless scraping. Build against sources you're allowed to use.
What calendar source do you trust enough to size on — API, IR pages, or something else?
Anyone automate confirmed vs estimated and still got burned by a time change?
How do you alert yourself when the parser fails instead of going silent?
DST bugs — war story? I've got one if you don't.