The hard-coded "2026-05-14T13:00:00.000Z" reading was due to fall out
of the snapshot's 14-day `recent` window two weeks after the suite
landed, deterministically breaking the assertion. Anchor the instant
to "today minus 2 days at 13:00 UTC" so it always sits inside the
window, then derive the expected Auckland / Berlin day-keys from
that instant. Keeps the test asserting the same tz-divergence
invariant without baking a calendar date into the suite.
Up to v1.4.24 the snapshot's day-key and weekday labels ran through
utcDayKey() / utcWeekday() / isoWeekKey(), so a 23:50 Pacific/Auckland
reading was filed under the next UTC day and the Coach replied with
the wrong calendar. The pipeline now reads User.timezone (alongside
the existing coachPrefsJson read so the read budget is unchanged) and
threads it through every bucketing helper (dailyMeans, bucketWeekly,
buildDailyValueRows, buildDailyBpRows) plus the medication-compliance
day-roll-up and the Apple Health additive blocks.
The prompt-budget calculator (src/lib/ai/coach/budget.ts) is unaffected.
The ledger still uses UTC midnight for spend roll-over because the
operator's LLM bill cycles on UTC; only the SNAPSHOT itself shifts to
the user's calendar. The provenance counts are row counts, not day
counts, so no provenance drift either.
Integration test pins the boundary: a 13:00 UTC May 14 reading (=
01:00 NZST May 15) appears under "2026-05-15" in the Coach snapshot
for a Pacific/Auckland user. The same instant in Berlin would land on
May 14; the test asserts the snapshot does NOT bucket there.
Existing 88-test coach unit suite stays green (the mocked user row
returns no timezone, so the snapshot falls back to Europe/Berlin and
the v1.4.24 byte-shape holds).
Four chart components (HealthChart, MoodChart, MedicationComplianceChart,
ComplianceLineChart) now accept a userTimezone prop, default
"Europe/Berlin" for backwards compat. Inside each chart, the X-axis
tick formatter, tooltip date label, and per-day bucketing all run
through a tz-aware makeFormatters(locale, userTz) instance instead of
the legacy formatDateShort() which pinned to Europe/Berlin.
Mount sites that already pull useAuth() pass user?.timezone:
dashboard /page.tsx, trends-row, recommendation-card,
insight-advisor-card. Ad-hoc usages without a user (storybook-style
or test harnesses) keep the default Europe/Berlin rendering
bit-for-bit.
The HealthChart's daily-aggregation key (toDayKey) was also rewritten
to depend on the userTimezone prop so a 23:50 Pacific/Auckland reading
buckets to the Auckland day instead of the Berlin day for chart data
display. The TanStack Query cache key gains userTimezone so a tz
change inside a session re-fetches and re-buckets correctly.
Tests: 109 chart-component tests stay green.
The four routes that bucket by Berlin calendar day (dashboard summary,
medication intake, analytics correlations and sleep, insights targets)
now read userTz from the authenticated User and pass it through
userDayKey(). Streaks and consistency strips for a Pacific/Auckland user
land on their Auckland-day, not the legacy Berlin-day.
The aggregation logic is unchanged — only the bucket key function
swaps from berlinDayKey(date) to userDayKey(date, userTz). Existing
Berlin users see no behaviour change (Europe/Berlin is the schema
default).
Integration test extended with a two-case assertion: the userDayKey()
boundary case (13:00 UTC May 14 → 2026-05-15 Auckland vs 2026-05-14
Berlin) and the dashboard summary route returning a non-zero streak for
an Auckland account with three consecutive Auckland-day measurements.
v1.4.25 W7 phase 7 — proposal §6.4 test strategy applied.
Seven cases cover the full per-user-tz pipeline against the
integration testcontainer:
1. CSV export for an Auckland user emits '+12:00' on measuredAt,
never the bare 'Z'. This is the issue #167 fix from the user's
end-to-end perspective: an Auckland user's exported spreadsheet
carries unambiguous local time.
2. CSV export for an Asia/Tokyo user emits '+09:00' (no DST in
Japan, deterministic offset year-round).
3. CSV export with no userTz (legacy library callers — admin tools,
canonical backup-on-disk) keeps the 'Z' suffix. Protects the
backward-compatibility path.
4. PUT /api/auth/me/timezone writes the new zone, the user row
reflects it, AND the in-process resolver cache returns the new
value immediately (the route invalidates on write — proves the
evict path works without waiting 60s for the TTL to roll).
5. PUT /api/auth/me/timezone rejects an invalid IANA zone with
422 and does not touch the column.
6. POST /api/auth/register captures a browser-detected zone from
the signup payload onto User.timezone.
7. POST /api/auth/register falls back to Europe/Berlin when the
payload's zone is invalid. The 'admin server default'
intermediate fallback layer is exercised by the unit suite —
the integration test runs against a testcontainer whose
migration history doesn't carry every AppSettings column,
so setting a non-NULL default would error before the route
runs. Documented inline.
The Coach snapshot's UTC bucketing (proposal §3 symptom 9) is
intentionally NOT asserted — that surface is deferred to a
follow-up wave because the snapshot's day/week bucketing pipeline
is a separate refactor that touches the prompt budget calculator.
Marc-André Bombeck