Bug: Transaction modal date field does not abide user preferences

[xBlaz3kx]

Before you start (required)

General checklist

• I have removed personal / sensitive data from screenshots and logs
• I have searched existing issues and discussions to ensure this is not a duplicate issue

How are you using Sure?

• I was a paying Maybe customer (hosted version)
• I use it on PikaPod, Umbrel or similar (VPS included)
• I am a self-hosted user (local only)

Self hoster checklist

Paying, hosted users should delete this entire section.

If you are a self-hosted user, please complete all of the information below. Issues with incomplete information will be marked as Needs Info to help our small team prioritize bug fixes.

• Self hosted app commit SHA (find in user menu): 16a1569
  • I have confirmed that my app's commit is the latest version of Sure
• Where are you hosting?
  • Render
  • Docker Compose
  • Umbrel
  • PikaPod
  • Other (please specify)

---

Bug description

When adding a new transaction to the account, the Date field does not abide my user preferences format but defaults to MM/DD/YYYY.

To Reproduce

Be as specific as possible so Sure contributors can quickly reproduce the bug you're experiencing.

Steps to reproduce the behavior:

1. Go to Settings -> Preferences (/settings/preferences)
2. Set Date format to DD.MM.YYYY
3. Go to home
4. Go to any Account (/accounts)
5. Click + New -> New transaction

Expected behavior

Transaction modal date field abides the user preference. It should display date in DD.MM.YYYY format instead of MM/DD/YYYY format.

Screenshots and/or recordings

[dosubot]

Hi @xBlaz3kx! I'm Dosu and I’m helping the sure team.

The transaction modal's date field uses a standard HTML5 <input type="date">, which means its display and format are controlled by the browser, not by your user preferences. Even though your preferred date format (like DD.MM.YYYY) is stored and validated in the backend, the modal does not currently apply this preference to the date input—it defaults to the browser's locale or a fixed format such as MM/DD/YYYY. To have the modal respect your chosen date format, the app would need to use a custom JavaScript date picker that can be configured with your preference, instead of the native browser control. This is a known limitation and is being tracked in the open issue you referenced.
Source: transaction modal form implementation

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[xBlaz3kx]

@jjmata can this be addressed? Seems like Dosu wont do it 😄

[jjmata]

Not sure what's expected. If you have your system locale set one way, and the app in another: what should take precedence? For instance: if I have my browser set to accept-language in Spanish first, but my application settings to English - what's consider UX best practice?

[jjmata]

(sorry if I'm ignoring your "Expected behavior" ... just not sure that's the best practice and this is not a show-stopper with all other major things going on/refactors/etc.)

[jjmata]

Happy to take a PR, obviously, and review a proposal that take this and other localized form fields into consideration (like 1,000.32 vs 1.000,32 thousands/decimals separators ... do those follow system defaults?) but currently trying to work on bigger things like a mobile native client (see #241) when I have a chance.