Apply Norwegian timezone and localized date formatting to timeline
epic-expense-approval-workflow-core-logic-task-015 — Ensure all timestamps in ClaimStatusAuditTimeline are converted from UTC to Europe/Oslo timezone before display. Use the intl package with nb_NO locale for date and time formatting. Display relative time (e.g. '2 hours ago') for events within the last 24 hours and absolute date-time for older events. Add WCAG 2.2 AA accessible semantics labels for each timestamp.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 7 - 84 tasks
Can start after Tier 6 completes
Implementation Notes
Create `ClaimTimestampFormatter` as a pure Dart class (no BuildContext, no Flutter imports) so it can be unit-tested without a widget tree. Inject `DateTime now` as a parameter rather than calling `DateTime.now()` inside — this is critical for deterministic tests. Use `tz.TZDateTime.from(utcTimestamp, tz.getLocation('Europe/Oslo'))` from the `timezone` package for conversion. Do NOT use `DateTime.toLocal()` — device timezone may not be Europe/Oslo.
For relative labels, define a private enum or sealed class: `_RelativeInterval { justNow, minutes, hours }` to avoid magic string comparisons. Register the `nb_NO` locale in `main.dart` alongside other locales to avoid the `MissingLocaleError` at runtime. When constructing the `Semantics` label, format the full absolute datetime even if the display shows relative time — this is required for WCAG 2.2 AA compliance.
Testing Requirements
Pure Dart unit tests (no Flutter widgets needed) for `ClaimTimestampFormatter`: (1) UTC timestamp 30 seconds ago → 'Just now'; (2) UTC timestamp 90 minutes ago → '1 time siden' (nb_NO locale); (3) UTC timestamp 25 hours ago → absolute format in nb_NO; (4) UTC timestamp exactly at 24-hour boundary; (5) a timestamp during CET (winter, UTC+1) displays correct local time; (6) a timestamp during CEST (summer, UTC+2) displays correct local time — this tests DST handling; (7) assert semantics label is always absolute format. All tests use a fixed `now` parameter — never `DateTime.now()` in test logic.
The ThresholdEvaluationService is described as shared Dart logic used both client-side and in the Edge Function. Supabase Edge Functions run Deno/TypeScript, not Dart, meaning the threshold logic must be maintained in two languages and can diverge, causing the server to reject legitimate client submissions.
Mitigation & Contingency
Mitigation: Implement the threshold logic as a single TypeScript module in the Edge Function and call it via a thin Dart HTTP client wrapper for client-side preview feedback only. The server is always authoritative; the client version is purely for UX (showing the user whether their claim will auto-approve before they submit).
Contingency: If dual-language maintenance is unavoidable, create a shared golden test file (JSON fixtures with inputs and expected outputs) that is run against both implementations in CI to detect divergence immediately.
A peer mentor could double-tap the submit button or a network retry could trigger a duplicate submission, causing the ApprovalWorkflowService to attempt two concurrent state transitions from draft→submitted for the same claim, potentially resulting in two audit events or conflicting statuses.
Mitigation & Contingency
Mitigation: Implement idempotency in the ApprovalWorkflowService using a database-level unique constraint on (claim_id, from_status, to_status) per transition, combined with a UI-level submission lock (disable button after first tap until response returns).
Contingency: Add a deduplication check at the start of every state transition method that returns the existing state if an identical transition is already in progress or completed within the last 10 seconds.
Claims with multiple expense lines (e.g., mileage + parking) must have their combined total evaluated against the threshold. If individual lines are added asynchronously or the evaluation runs before all lines are persisted, the auto-approval decision may be computed on an incomplete set of expense lines.
Mitigation & Contingency
Mitigation: The Edge Function always fetches all expense lines from the database (not from the client payload) before computing the threshold decision. Define a clear claim submission contract that requires all expense lines to be persisted before the submit action is called.
Contingency: Add a validation step in ApprovalWorkflowService that counts expected vs. persisted expense lines before allowing the transition, returning a validation error if lines are missing.