Per-user locale preferences (date format, time format, first day of week)

[ArgonQQ]

Problem

Date and time formats are hardcoded across the app:

• Dates render as YYYY-MM-DD everywhere (entries table, reports, PDF, customer/user Created timestamps).
• Times render as HH:MM 24h.
• Filter "This Week" implicitly starts on a fixed weekday.
• The language switcher (EN/DE) does not change date/time presentation.

Users in different regions expect their familiar formats — German users expect 21.04.2026, US users expect 04/21/2026 or Apr 21, 2026, etc. Tying the format to UI language is too coarse: a German user may want German UI but US date format, or an English user may prefer ISO.

Proposed solution

Add a per-user preferences section in the Account modal with three dropdowns:

Date format

• 2026-04-21 (ISO, default)
• 21.04.2026 (DE)
• 21/04/2026 (UK / ROW)
• 04/21/2026 (US)
• 21 Apr 2026 (long)

Time format

• 14:30 (24h, default)
• 2:30 PM (12h)

First day of week (used by the "This Week" filter)

• Monday (default)
• Sunday

Affected surfaces

Apply the user's chosen formats wherever dates/times are displayed:

• Entries table (Date column, From/To time columns)
• Reports table (per-row Date)
• PDF export (per-row Date, custom date-range header)
• Date-range filter labels (custom range)
• User and customer Created timestamps
• Account modal's email/password change confirmations if any

Out of the user's locale (intentionally)

• CSV export — stays ISO YYYY-MM-DD and 24h HH:MM regardless of user setting, so spreadsheets and scripts can parse it.
• Timer display (00:00:00) — it's a duration counter, not a wall clock; no AM/PM applies.
• <input type=\"date\"> — controlled by the browser locale; cannot be overridden.

Storage

Extend the users table with three columns (or a single preferences JSON column):

• date_format (string identifier, e.g. iso / de / uk / us / long)
• time_format (24h / 12h)
• first_day_of_week (mon / sun)

Defaults inferred from Accept-Language / browser locale on first login, then user-overridable.

UI

New section in the Account modal labeled Display Preferences (DE: Anzeigeeinstellungen). Saved via existing PATCH-style endpoint pattern.

Alternatives considered

1. Tie format to UI language (tt_lang) — simplest, but conflates language with regional format; users want to mix them.
2. Use navigator.language directly — no opt-out for users on shared devices or unusual locales.
3. Use Intl.DateTimeFormat with a single locale string per user (e.g. en-GB, de-DE) — more flexible but exposes too much complexity in the UI; the dropdown approach is clearer.

The dropdown approach was preferred because it gives users explicit control with named options, decoupled from UI language.

Additional context

• Storage layer is unaffected: dates already stored as ISO YYYY-MM-DD strings and times as HH:MM. Only the display layer changes.
• Need a small formatDate(iso, user) / formatTime(hhmm, user) helper pair, used everywhere display code currently emits raw values.
• Time zones are explicitly out of scope — entries remain naive local time as today.
• Adding new UI languages beyond EN/DE is out of scope.
• The existing PDF export already formats custom date ranges as DD-MM-YYYY (#PR2); that hardcoding should be replaced by the user's preference.