fix: count down to a game's reset, not to UTC midnight

A source that prints "August 19, 2026" and no time is stored at 00:00Z,
which is a placeholder for "somewhere in this day" rather than a claim
about when the day opens. The countdown read it literally, which turns it
into exactly that claim — and the UTC day is nobody's. Wuthering Waves
events dated the 19th were still running three hours after we had retired
them, because a European player's day opens at 04:00 on a UTC+1 server;
Asia was four hours out the other way and America nine. Sixty-two of the
eighty-six published events were affected, across ten of thirteen games,
so the reader was reading a wrong number far more often than a right one.

A day-precision boundary now resolves to the reset that opens that
game-day on the reader's server — the same grid daily.ts keys every tick
by, and the only clock we hold for a game. That is a reading of the date
the source printed, not a time invented for it: nothing stored moves, no
event ID moves, and the parsers still refuse to guess.

Two boundaries are never re-anchored. A regionEnds value is already the
instant a source stated per server, so anchoring it would throw a fact
away. And an event the reader typed in was resolved by readerInstant in
their own timezone, which is a stated time too — theirs.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
This commit is contained in:
Lucas Winther
2026-08-18 21:48:29 +02:00
co-authored by Claude Opus 5
parent 00c3f5e2da
commit 4334988ecf
6 changed files with 248 additions and 13 deletions
+18 -1
View File
@@ -79,6 +79,23 @@ true`, with `regionEnds` carrying the three resolved UTC instants. The client pi
user's stored region (PRD F5). Collapsing these into a single timestamp loses up to 13 hours of
accuracy and will make the countdown wrong for two thirds of users.
**`startPrecision` / `endPrecision`, and what 00:00Z means.** A source that prints a calendar date
and no time of day gets `"day"` precision, and the instant stored alongside it is that date at
00:00Z. That timestamp is a **placeholder for "somewhere in this day", not a claim that the day
begins at UTC midnight** — the parser has declined to invent a time, exactly as it declines to
invent a date. Nothing downstream may read it as an instant: `clockFor` in `src/shared/time.ts`
resolves a day-precision boundary to the reset that opens that game-day on the reader's server
(`dayStartMs`), which is the same clock `daily.ts` keys every tick by, and the countdown and the
detail sheet both run off that. Read literally instead, the stored value expires an event up to nine
hours early — the whole of Asia and Europe — which is how a Wuthering Waves event dated "August 19"
was called over three hours before the game ended it.
Two boundaries are exempt, for the same reason in both directions. A `regionEnds` value is taken
verbatim: that map only exists because a source published a timer per server, so it is already the
instant, and re-anchoring it would throw a stated fact away. And an event the reader typed in
(`extractionMethod: "manual"`) is taken verbatim too: `readerInstant` resolved it to the instant
*they* meant, in their own timezone, when they entered it.
**`confidence`** is assigned by the parser and adjusted during merge and reconciliation — see
`docs/INGESTION.md` § Scoring. It records how firmly the sources pinned the event down.
@@ -392,7 +409,7 @@ to:
| Rule | Why |
|---|---|
| `endsAt` null pairs with `endPrecision: "unknown"` | The same invariant `GachaEvent` enforces. "I don't know when this ends" is a supported answer for a reader too, and a required one — otherwise entering an unannounced event forces them to invent a date |
| A date with no time is `"day"` precision, a date with one is `"exact"` | So the UI's existing "accurate to the day only" note is honest about their input as well |
| A date with no time is `"day"` precision, a date with one is `"exact"` | So the UI's existing "accurate to the day only" note is honest about their input as well. Their day-precision boundary is still *their* instant, though — `readerInstant` puts a start at 00:00 and an end at 23:59:59 in their own timezone, so unlike a parser's placeholder it is never re-anchored to a server reset |
| `endsAt` must be after `startsAt` | A backwards interval is a typo whoever made it |
| `hue` must match `#rrggbb` | It reaches a `style` attribute, and an imported file is not necessarily one the reader wrote |
| `regionScoped` is always false | They entered one instant, not a per-region map. Claiming otherwise would fabricate three timestamps out of one |