fix(i18n): preserve literal calendar dates in offer comparisons

2026-11-04 01:58:27 +01:00
parent 09904ecc68
commit df0ef68cd9
6 changed files with 52 additions and 10 deletions
@@ -0,0 +1,7 @@
+# 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.
+
+Next: after sealing the public-auth export, build this fix and run affected rendered offer 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.