blocker fix phase 4

2026-08-02 21:27:34 +03:30
parent dd3e39dec5
commit 08949a24de
4 changed files with 56 additions and 2 deletions
@@ -30,3 +30,18 @@ the in-memory `Kind` tag changes on read.
 anywhere else a server-frozen instant feeds a client countdown (e.g. `dispute_window_ends_at`, BNPL
 `settled_at`) — worth a grep for other `DateTime` (not `DateTimeOffset`) properties before considering this
 class of bug fully closed, not just the one already reported.
+
+**Follow-up from that grep (done, not yet fixed).** Swept every other `DateTime`/`DateTime?` entity property
+(`BaseEntity.CreatedAt`/`ModifiedAt` already correctly use `DateTimeOffset` and are excluded). Most are
+internal/audit-only (payout batches, webhook events, ASP.NET Identity tables) and never reach a client. Four
+are real, lower-severity instances of the same bug — never wired to a live countdown, so the failure mode is
+"can show the wrong day near a Tehran midnight boundary," not "actively expires while showing time left":
+- `Booking.DisputeWindowEndsAt` (`Entities/Booking/Booking.cs:95`) — rendered via `formatShamsiDate` in
+  `BookingDetailView.tsx:444`.
+- `Booking.ConfirmedAt` / `CancelledAt` / `CompletedAt` (`Entities/Booking/Booking.cs:73,74,91`) — booking
+  timeline timestamps shown to the client.
+
+All four are configured in `BookingConfig.cs` (no `.HasConversion(...)` today) and would take the exact same
+fix as this phase: `.HasConversion(new UtcDateTimeConverter())`. Deliberately left unfixed here — scoped out
+of this phase on request, tracked so it isn't dropped. Pick up as a follow-up phase (or fold into
+[13-booking-lifecycle.md](13-booking-lifecycle.md), which already touches `Booking` timezone handling).