A server page renders the family's date: 24 zone-less date renders on 13 family server files, and the three emails take the family's zone

[NewWorldVenture]

What

A family-facing server page, server action or email now renders a date in the family's zone, not the host's.

toLocaleDateString(locale, { month, day }) with no timeZone renders in the zone of the machine running it. In a browser that is the reader's own clock. On the UTC host that renders a server component or runs a cron it is Greenwich's, and from 5pm in California Greenwich is already on tomorrow. #932 ratchets the API routes and server libraries; this PR covers the two roots it does not: the server pages and actions under app/(app), and the email templates under lib/emails. Twenty-four renders across thirteen page files plus the three emails' "today" / "due" lines read the host's clock.

How

Surface	Before	Now
home	badge month + d.getDate(), due day, photo day via toLocaleDateString(locale.code, …)	the formatter the page already binds to tz: fmtDate(…, 'MMM' / 'd' / 'MMM d')
memories, planning, food	fmtDay(x, locale) helpers on toLocaleDateString	getFormat(tz).fmtDate; a DATE column renders in no zone, an instant in the family's
conflicts	both ends host-zoned; "same day" by toDateString()	timeZone: tz on each; same day by dayKeyInTz
concierge run history, playbook tradition month	host zone	timeZone: tz
sync history, sync account "last synced", social post attempts	bare toLocaleString() (host zone and host locale)	fmtDate(…, 'MMM d, yyyy h:mm a')
treasury	6-month trend bucketed and labelled by the host's months	buckets by dayKeyInTz(created_at, tz).slice(0, 7), "this month" from the family's first, DATE-only labels
display birthday	built and rendered in the host zone (right by accident)	built and rendered in one explicit zone
weekly digest	"Week of" host date; event day key re-parsed in host zone	timeZone prop from the route's tz; day keys rendered in UTC so they stay that day
notification digest	host date	sender reads families.timezone once per batch; a failed read logs and dates in explicit UTC rather than holding the digests
chore reminder	bare toLocaleDateString()	'en-US' + the family's zone, selected with the family name

Tests

tests/a-server-page-renders-the-familys-date.test.ts (17 cases): the formatter contract the pages rely on; the three emails rendered at 2026-10-04T00:30Z in Los Angeles and UTC (a chore due 7pm Sunday in California is "Due Oct 4", not Oct 5); per-caller and per-page pins; and a ratchet over the server files under app/(app) and lib/emails. The admin tree (8 sites) is excluded on purpose for its own unit, and a case fails the moment the exclusion stops excluding anything.

Mutation controls, each against the unmodified test with the file restored byte-for-byte:

Mutation	Cases that fail
zone dropped from the weekly digest	2
zone dropped from the notification digest	2
zone dropped from the chore reminder	2
timeZone: tz dropped from one conflicts label	2
one food label reverted to toLocaleDateString	2
digest sender dating every recipient in UTC	1

Tests adjusted: four tests whose requireUserContext stubs lacked active.family (the playbook action and the social post page now read its zone), the chore-reminder membership pins, the react-email render test's props, and the one-time-ago browser-locale count, now zero with its instrument proved on planted lines.

Validation: the 110 touching test files (1636 cases) green under UTC and TZ=America/Los_Angeles except the react-email render file, which fails identically on clean main in this container; ten repo-wide locale and zone ratchets (56) green; tsc and eslint clean. The full suite in this container is 1866 files passed, 8 failed (34 cases), and those 34 cases are identical, by name, to the 34 that fail on clean main 40bf5ff in the same container (the Node version pin, the stream-cancellation runtime, the react-email render path, the react-dom production hook, and four marketing pages on the same render stack): environment, not this change; CI is the arbiter. No migration, no schedule, no credential, no live send.

Follow-ups (not in this PR)

• The admin tree's 8 sites, then the ratchet's exclusion and its guard case are deleted together.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KP9rt5rVQ9jDMpZp2xBy3K

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
bubaly	Ignored		Oct 4, 2026 5:01am UTC

[NewWorldVenture]

Review finding: a user digest can apply one family's timezone to notifications from another family.

groupByUser(permitted) combines all permitted rows for the same user, then the email formatter picks the zone from notifs[0].family_id for the whole digest. Repro: give one user active memberships in Family A (America/Los_Angeles) and Family B (Pacific/Kiritimati), add one permitted notification per family around a UTC date boundary, and render the combined digest with A's notification first. B's date is rendered in A's zone and can show the wrong calendar day.

The added test currently asserts the first-row family choice and renders a single-family email, so it does not exercise this case. Please group/render per family or avoid a family-specific date header for mixed-family digests, and add the two-family regression case.

[NewWorldVenture]

Confirmed and fixed in 138f9ea.

The fix. The digest's date line is a family's day, so it is only honest when every family in the digest keeps the same zone. A new pure helper, digestTimeZone(notifs, zoneByFamily) in lib/notifications/digest.ts, returns that zone, or null when the recipient's families differ. The sender passes that instead of zoneByFamily.get(notifs[0].family_id), and the template takes timeZone: string | null: with null the greeting reads "here's what's coming up." with no date at all, rather than one family's day over another family's rows. A batch whose zones could not be read still dates in an explicit UTC, as before. I chose "no date" over per-family rendering so a recipient keeps getting one digest, one send and one idempotency key.

Regressions.

• tests/notification-email-membership.test.ts: the two-family case against the real sender, with the fixture now serving families and capturing the rendered element. Family A in America/Los_Angeles, Family B in Pacific/Kiritimati, one permitted row each, clock at 2026-10-04T00:30Z (Saturday the 3rd in LA, Sunday the 4th in Kiritimati), A's row first: one digest, both rows settled, timeZone null, and the HTML carries neither "October 3" nor "October 4". Also: reversing the row order does not pick a zone; two families in the same zone stay dated in it; one family stays dated in its own; an unreadable zone is an explicit UTC.
• tests/notification-digest.test.ts: the helper's four cases.
• tests/a-server-page-renders-the-familys-date.test.ts: the render-level case for a null zone, and the source pin now names the new expression and forbids the notifs[0].family_id lookup.

The fix is merged up the stack into #943, #944 and #945.

---

Generated by Claude Code