The session date is a fact the provider already holds. Every attempt to derive it is a re-implementation of somebody else's calendar.
Three ways to get the date, ranked
Once you accept that the machine's calendar is not the market's, there are three candidate fixes, and only the third one holds.
Subtract a fixed offset. "New York is UTC minus five, so subtract five hours before taking the date." This is wrong twice a year in each direction, and the failures cluster exactly where nobody is looking — the week after a daylight saving transition, in one market but not the others.
Consult an exchange calendar. Better, and now you own a table of exchange hours and holidays for three countries, which is a second source of truth that drifts. You will find out it drifted when a market has an unscheduled half-day.
Ask the provider. The quote already carries the moment it was taken and the name of the exchange's timezone. Converting one through the other yields the session date the exchange itself would use. No table, no offsets, no drift — because the answer comes from the same place as the value it describes.
What the implementation actually does
The function is short and the interesting parts are its edges. It reads two fields — the epoch-second timestamp of the last regular-market moment, and the exchange's timezone name — builds an aware datetime in UTC, converts it into the exchange's zone, and takes the date.
Note that it does not convert into the server's zone. The intermediate representation is UTC because that is unambiguous, but the destination is the exchange, because the exchange is who defines what session this is.
The fallback is where honesty lives
The function returns None when the provider is silent — no timestamp, no zone name, or an unparseable one. It does not guess. Its docstring then says callers fall back to the UTC date and say so, rather than inventing a calendar.
That last clause is the whole discipline in miniature. A fallback that is indistinguishable from the real thing is not a fallback, it is a silent downgrade — and downgrades that leave no trace are how a system's accuracy erodes without anybody being able to point at the moment it happened.
When this lesson was first written, that clause was not implemented. The caller substituted a fallback date and stored the provider's original source string unchanged, so a fallback-dated row was byte-identical in provenance to a provider-dated one. The honest half — returning None instead of guessing — was real and load-bearing; the disclosure half lived only in the docstring. A comment describing what the code does is a claim, not evidence. This one had been quoted, believed, and repeated — including by an earlier draft of this lesson.
And on 2026-08-31 it was closed
What closing it looked like teaches more than the gap did. Nobody touched the fallback date — that part was always right. What changed is the source string that travels beside it. The two call paths each carried their own private fallback helper; both were retired and replaced by a single seam both now go through. Provider stated a date: the source is passed along untouched. Provider silent: the UTC date goes out with (date:utc-fallback) appended. That is the entire fix.
Three things are worth taking. First, the fix reached the storage layer. Not a log line, not a metric — the row itself changed, because this store's invariant is provenance on every stored value, and which of the two kinds a date is is provenance. Second, the branch collapsed to one place. Two call sites were falling back independently, so the defect existed in duplicate, and fixing one would have left the other sitting there quietly. Third, the regression test pins both branches — including that a provider-dated row must come back untagged. A test asserting only that the tag appears is also passed by an implementation that tags everything.