Felix Förtsch
c0bcbaec1b
All checks were successful
Build and Push Docker Image / build (push) Successful in 49s
the previous TimeInput was a bespoke two-field widget. correct in behaviour
but off-policy: we don't roll our own ui primitives when a maintained
library solves it. swap for react-aria-components + @internationalized/date
pinned to hourCycle={24}, granularity=minute, shouldForceLeadingZeros so
the output is always strict HH:MM regardless of browser/OS locale.
wrapper lives at src/shared/components/ui/time-input.tsx and keeps the
existing string-based API (value: "HH:MM", onChange(next)) so callers don't
change.
also updates the stack docs: web-stack.md now pins react-aria-components
as THE required library for every date/time ui; iOS and Android entries
mark their canonical component as TBD and explicitly forbid rolling our
own without user sign-off.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1.6 KiB
1.6 KiB
name, description, type, originSessionId
| name | description | type | originSessionId |
|---|---|---|---|
| Never use locale-aware time/number widgets | Use src/shared/components/ui/time-input.tsx (wraps react-aria-components TimeField) and formatThousands helper — never `<input type="time">` or `toLocaleString()` | feedback | de22fecc-a14b-436f-b6c2-55e545bca160 |
In this project, times render as 24h HH:MM and numbers with a comma thousands separator regardless of browser/OS locale. Never reach for:
<input type="time">,<input type="date">,<input type="datetime-local">— Chrome on macOS in en-US renders AM/PM, Safari in de-DE rendersDD.MM.YYYY, no attribute overrides this reliably.Date.prototype.toLocaleString(),toLocaleDateString(),toLocaleTimeString(),Number.prototype.toLocaleString()— silently flip separators/format per locale.
Use instead:
TimeInputfromsrc/shared/components/ui/time-input.tsx— a thin wrapper aroundreact-aria-componentsTimeFieldpinned tohourCycle={24},granularity="minute", emits strictHH:MM.formatThousands()fromsrc/shared/lib/utils.tsfor number grouping.- If a new need (date field, range picker) appears, extend using the same
react-aria-components/@internationalized/datetoolkit — we are committed to that library for every date/time UI on this project. Do not hand-roll a parallel component (the user stopped me on 2026-04-13 when I started doing that — they want maintained libraries, not bespoke inputs).
Why: AGENTS-web-stack.md now mandates this stack-wide. The user was emphatic ("FUCK THIS" on AM/PM, 2026-04-13); keeping ISO 8601 consistent is a core product constraint, not a nice-to-have.