cesnimda
1.7 KiB
Offer calendar-date display
4 November 2026. V11 is reproduced by controlled string fixtures: a literal 2026-12-01 displayed as30 November in America/Los_Angeles. The offer fact formatter now selects UTC only for exact YYYY-MM-DD strings. Timestamp strings retain their existing local-time formatting; missing values retain the unknown marker. No stored value, API contract, timezone provenance, deadline precision, query, mutation or route changes.
RED: two western-timezone EN/NB failures, four other timezone cases passed and nine existing cases filtered. GREEN: all15 offer comparison tests passed, including six EN/NB combinations for Los Angeles, Oslo and Kiritimati plus timestamp, missing-value, navigation, salary, retry and read-only behavior. TypeScript and scoped ESLint passed. Independent read-only review found no actionable findings and ran no checks. Public-auth browser evidence predates this unbuilt change and does not qualify it.
Rendered PASSED on settled successora7d72673: six390px journeys/scans/captures, EN/NB across Los Angeles, Oslo and Kiritimati. Chromium timezone contexts preserve the literal application date and decision date while a genuine follow-up timestamp retains its local calendar day. Unknown facts remain visible. Zero browser errors or mutations. Static build passed; the existing secondary-route verifier's opt-in offer-only mode preserves earlier outputs. This is a targeted timezone check, not a new full secondary regression or real backend qualification.
Rollback reverts the formatter and six added tests; no migration. This does not assert that deployed API records use literal date-only serialization, or resolve the separate original timezone/precision model gaps.