A user reported that my TV tracker was showing the wrong air date for Silo. Their favourites card said the next episode aired today. Google said tomorrow. One of us was wrong, and the obvious assumption was that it was me.
It was — but not for the reason I first thought, and the underlying cause is worth writing down, because it affects any app built on the same data.
First, a genuine bug of my own
The initial report was that the same episode showed different countdowns in different places in the app: a show card said "airs tomorrow" while the notification for the same episode said "airs today".
That one was mine. Two different pieces of code were deciding what "today" meant in two different ways. One compared calendar days entirely within the show's own country's timezone. The other took the show's end-of-day cutoff, converted that instant into the viewer's local timezone, and compared calendar days there.
Those two approaches agree only when the show's timezone and the viewer's are close together. For a US show viewed from Germany — a nine-hour gap — they routinely land on different calendar days, shifting the whole today/tomorrow boundary depending on what time of day you happened to look.
I fixed it by making both read from one shared function that only ever counts days in a single timezone. The two displays then agreed with each other perfectly.
They were also both still wrong.
The part that wasn't my code
With the app now internally consistent, Silo still said "airs today" for an episode that Apple, and everyone reporting on it, placed the following day. So I checked the source data against published release dates.
Like a great many TV apps, this one gets show data from TMDB. Here's what its air_date field said for two consecutive Silo episodes, next to the dates in press coverage:
| Episode | TMDB | Actually released |
|---|---|---|
| S3E6 "The Drive" | Thu 6 Aug | Fri 7 Aug |
| S3E7 "Radio" | Thu 13 Aug | Fri 14 Aug |
Both exactly one day early. Both a Thursday where the real release was a Friday — matching Silo's actual weekly Friday schedule. Two consecutive episodes ruled out a one-off typo.
Why the date is "wrong" on purpose
It isn't a typo. TMDB's convention is that air_date records the earliest calendar day an episode becomes available in its country of origin — not the date the platform advertises.
For a traditional broadcaster those are the same day. For a global streaming service they aren't. A TMDB moderator spells it out in their "Clarification on Air Date policy" thread:
"Amazon Prime release its new content at 0h GMT and Apple TV at 0h Ireland Time on the advertized date, which means that the content is available in the evening of the previous day in the United States. If its a United States show, the recorded date is this previous day and if its an European show, the recorded date is the advertize day."
That last sentence is the part worth reading twice, and the part I initially got wrong.
The shift is not a property of the service. It depends on the show's origin country: midnight in Ireland is still the previous evening in Los Angeles, but it's simply midnight in London. So a British show on Apple TV+ is recorded under its advertised date, with no gap at all.
I checked, because my first version of the fix ignored that clause. Slow Horses is a British series on Apple TV+: TMDB says 29 October, and so does the press. Shifting that one — as my first attempt would have — would have made it a day late. The same bug pointing the other way.
A control case, because one pattern isn't a rule
The obvious risk here is over-correcting: deciding "TMDB is a day early" and shifting everything, which breaks every show that was already right.
So I checked a show releasing the same week on a different service: Stuart Fails to Save the Universe, on HBO Max. TMDB said 13 August. Press said 13 August. No gap.
The discrepancy isn't general to TMDB, or to streaming, or even to every show on these services. It needs both conditions at once: a service that releases globally at a single instant, and an origin country far enough west that the instant lands on the previous local day.
A reader's example, and the detail that explains it
After this went up, a commenter pointed out the same thing with the Ted Lasso season four premiere — a cleaner example than mine, because the advertised date comes from Apple directly.
TMDB has the episode on 4 August. Apple's own press release says the season returns Wednesday 5 August. It went live at 9pm Eastern on the 4th — the night before the date Apple itself advertised.
The same commenter mentioned something that turns out to be the root of the whole problem: TMDB records a date, with no time attached.
That's why this can't be resolved inside TMDB. "4 August" is a complete answer if you also know the release happened at 9pm Eastern; it's ambiguous if you don't. A timestamp would let every consumer convert correctly for its own audience. A bare date forces each of them to reconstruct the missing hours — which is exactly the reconstruction this post is about.
What I actually did
The app now reads a show's network and its origin country together. The date is shifted forward to the advertised release only when the service is one of these two and the origin country sits behind Irish time — decided by comparing the two timezones, rather than by keeping a list of countries.
Concretely: Silo (American) shifts. Slow Horses (British) doesn't, despite both being Apple TV+ originals released the same way.
If you build on TMDB
Three things worth taking away.
air_date means "earliest availability in the origin country", not "the date this is advertised as". Most of the time there's no difference. For globally-released streaming shows there is, and it will look like your app is broken.
The correction is narrower than it first appears. It would have been easy — and wrong — to shift everything on those two services. Half the fix is knowing when not to apply it.
Agreement isn't correctness. I fixed a real inconsistency in my own code, the two displays started agreeing with each other, and that felt like success. It was only checking against the outside world — the thing the user did, and I hadn't — that surfaced the actual problem. Then I repeated the mistake in miniature by shipping a network-only rule without checking a British show against it.
