Context
Currently formatNumericDate in wordkeep-client/src/app/utils/date-format.ts hardcodes DD/MM/YYYY. This is fine for our current users but will misread for US users (who expect M/D/YYYY) and others.
Proposed approach
When we expand to international users, swap the helper to use the browser locale:
new Intl.DateTimeFormat(undefined, { dateStyle: 'short' }).format(d)This gives each user the format their browser locale expects. Single chokepoint — one file change.
If complaints follow
Add a user preference on the profile (date_format: 'auto' | 'DMY' | 'MDY' | 'YMD') that overrides browser locale. Don't pre-build this — wait for actual demand.
Out of scope
- Existing month-name dates (e.g. `Jan 15, 2024`) already use locale-aware formatting and don't need changing.
- Backend storage stays UTC ISO 8601.
Trigger
When we onboard non-EU users, or before any marketing push outside RO/EU.
Context
Currently
formatNumericDateinwordkeep-client/src/app/utils/date-format.tshardcodes DD/MM/YYYY. This is fine for our current users but will misread for US users (who expect M/D/YYYY) and others.Proposed approach
When we expand to international users, swap the helper to use the browser locale:
This gives each user the format their browser locale expects. Single chokepoint — one file change.
If complaints follow
Add a user preference on the profile (
date_format: 'auto' | 'DMY' | 'MDY' | 'YMD') that overrides browser locale. Don't pre-build this — wait for actual demand.Out of scope
Trigger
When we onboard non-EU users, or before any marketing push outside RO/EU.