Point-in-time data joins need revision availability timestamps to avoid wrong historical answers

An as-of join can execute without error yet return an incorrect answer to a historical question, because what matters is when each version of a value became available. In a synthetic example, a September figure published October 3 at 100 and revised October 7 to 80 should still yield 100 for an October 4 decision. Joining the latest revision to earlier dates would wrongly produce 80, so a useful test is that adding a later revision must not alter a past selection. The author's code enforces explicit timezones, rejects equal-timestamp revisions as ambiguous, and passes four synthetic checks. The piece cautions that this is a small illustration rather than a trading strategy or complete financial model, and that replaying what a live system knew requires actual receipt history, not just publication times.