Problem

Transaction history showed times 8 hours behind Taipei. Root cause: event timestamps used LocalDateTime (a zone-less wall clock) written into TIMESTAMP WITHOUT TIME ZONE columns and stamped via LocalDateTime.now() in a UTC container — so the stored numbers were UTC wall clock and were rendered verbatim.

The same anti-pattern was latent in the audit path: AuditLog.createdAt is a LocalDateTime that crosses RabbitMQ as JSON, which drops the zone — correctness only held because every service happened to share one zone.

Fix — "store UTC absolute instant, convert at display"

• Types: Transaction / Member / AuditLog (wallet_system and audit-service) createdAt + lastLoginAt: LocalDateTime → Instant; all *.now() → Instant.now().
• Schema: V5 retypes transactions.created_at, members.created_at, members.last_login_at to TIMESTAMPTZ via USING ... AT TIME ZONE 'UTC' — a re-typing, not a data shift (the absolute moment is unchanged). This replaces an earlier UTC→Taipei row-shift migration that was never deployed.
• hibernate.jdbc.time_zone=UTC so storage is always the absolute instant.
• Filtering: TransactionSpec converts the user's Asia/Taipei date range to instants.
• Display: AppZone centralises the display zone; Transaction.getCreatedAtLocal() renders for the view; dashboard.html uses it.
• Container TZ: kept only for log readability / LocalDate.now() — no longer load-bearing for correctness.
• MongoDB: no migration — BSON Date already stores the absolute UTC instant; the type change just reads it back as Instant.

Verification

• Testcontainers Flyway IT (real Postgres): V5 applies, ddl-auto=validate accepts Instant↔timestamptz, date-range filter works.
• Full suites green: wallet_system 236, audit-service 2.
• New-code coverage 92.3% (gate ≥ 80%).

Deploy note

Prod never ran the earlier shift migration, so its existing UTC-naive values are correctly reinterpreted by the AT TIME ZONE 'UTC' retype. Flyway applies V5 automatically on the next up -d --build.

🤖 Generated with Claude Code