format-relative-date.test.tsfix(crm): "3h ago", not "Today", for everyone west of UTC
`formatRelativeDate` read two different calendars. The day branch built its comparison from
UTC components — deliberately, so a date-only value stored at midnight UTC does not slide
back a day for US viewers — and said so in a comment ending "BOTH sides must read the same
clock". The sub-24h branch three lines above it asked date-fns `isToday`, which reads the
LOCAL calendar. The one branch nobody re-checked was the one the comment was about.
West of UTC the two disagree for most of the evening. At 04:37Z on the 31st — 00:37 in New
York — a touch from 3h41m earlier is 20:55 on the 30th locally but still the 31st in UTC. So
`isToday` was false, the hour branch was skipped, and the day math, which had both on the
31st, answered "Today". A rep opening a deal after 8pm saw a meeting from that afternoon
labelled as though the hour did not matter.
The UTC day values are now computed once, above both branches, and the hour branch tests
those instead of the ambient zone. `isToday` is gone with it.
── Why the suite could not catch this ──
Every CI runner is UTC, and in UTC the two calendars cannot disagree, so all five existing
tests passed on the broken code. The suite even documented the hole — "keys off the viewer's
LOCAL calendar day by design, so it is not timezone-stable" — right under a test asserting
"3h ago", which is exactly the assertion that is not stable. UTC is not a neutral default for
date code; it is the blind spot.
So there is now a second pass, west of UTC: `tests/timezone/`, run by
`pnpm --filter @zero/mail test:tz` and by its own CI step, excluded from the main run so it
cannot pass vacuously there. TZ has to be set before the process starts — V8 caches the zone
on first use, so neither assigning `process.env.TZ` in a test nor a custom testEnvironment can
move it (I tried both; a guard test in the file now fails if the zone ever stops applying).
Verified the way a regression test has to be: the new suite fails on the old implementation
with exactly "Expected 3h ago, Received Today", and passes on the fix.
Co-Authored-By: Claude Opus 5 <<email>>Sep 8, 2026, 1:51 PM