"Never stamp today's date on a snapshot."
The line that looks fine
Somewhere in every data-collecting system there is a line that says, in effect, data_date = date.today(). It passes review. It passes type checking. It reads as obviously correct: we are storing today's reading, so we store today's date.
It is only wrong when the machine's calendar and the subject's calendar are different things — and once you say it that way, the surprise is that anyone ever expects them to agree.
The specific collision
The daily loop fires at 07:11 Asia/Seoul. That hour was chosen for good reasons: safely after the US close in both summer and winter, comfortably before the Korean open. It is also 22:11 UTC on the previous day.
So on the morning of August 6th in Seoul, the loop fetched the US close — which was the session of August 5th in New York — and stamped it with the local date: August 6th. Every US gauge row in the store now claimed to describe a session that had not happened yet.
Nothing crashed. No test failed. The value was correct, the source string was correct, the fetch timestamp was correct. Exactly one field was wrong, and it was the field the entire read model sorts on.
The fix was not argued into place, it was measured. At one instant on 2026-08-06, a US ETF proxy resolved to a session date of 2026-08-05 and a Tokyo-listed ETF resolved to 2026-08-06. Two listings, one moment, two different correct answers. That single observation kills every design that stamps one date across a multi-market pass, because it shows the disagreement is not an edge case — it is the normal state of a world with more than one exchange in it.
Why this class of bug is so quiet
Three properties combine, and they are worth recognizing in your own systems.
First, the wrong value is well-formed. It is a valid date, in range, in the right format. Every validation you would think to write passes.
Second, it is wrong by different amounts for different rows, and never uniformly. It is tempting to assume Seoul's date at least suited the Korean and Japanese gauges. It did not: those gauges are built on Tokyo-listed and US-listed ETF proxies, and at the moment the loop runs neither market has opened, so their newest completed session is also the previous day. Measured on the live engine, a pass finishing 22:11 UTC — 07:11 the next morning in Seoul — wrote US, Korean and Japanese rows all belonging to the same earlier session. The local date suited none of them. A defect that is wrong everywhere but by amounts that vary with the row does not look like a defect; it looks like a data source behaving oddly.
Third, the observer shares the defect. The developer reading the dashboard is also in Seoul, also thinking it is August 6th, and the number labelled August 6th looks exactly right to them. You cannot catch this by looking unless you already know to look.