fix(passwords): format saved dates with the app's locale - #31
Merged
Merged
Conversation
Settings advertised "May 21, 2026" while the Passwords app showed "17/07/2026". Two separate causes, both fixed here: 1. The date was never formatted in the UI at all. listVaultEntries() ran DATE_FORMAT(created_at, '%d/%m/%Y') in SQL, so the app just printed a string the server had already baked into UK/EU order - unreachable from the client and contradicting the Region the settings page claims. It now selects UNIX_TIMESTAMP(created_at) and the UI formats it via a new formatMediumDate() in lib/time.ts, which uses getLocaleTag() like the other shared date helpers. `created` is typed number (seconds) and the dev mocks were moved onto real timestamps. 2. The Settings row it was compared against was itself a hardcoded string, so it could never agree with anything. It now renders through the same helper. Verified across the shipped locales: the reported 17/07/2026 renders as "July 17, 2026" (en-US), "17 July 2026" (en-GB), "17 juillet 2026" (fr-FR). Unparseable/missing values return '' and the row hides, as before.
Github-Samuel
pushed a commit
that referenced
this pull request
Sep 15, 2026
Passwords showed a server-baked UK date string that couldn't match the region setting. The server now returns a UNIX timestamp and the UI formats it via a shared formatMediumDate() using the app locale, and the Settings date row renders through the same helper instead of a hardcoded string.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Settings advertised "May 21, 2026" while the Passwords app showed
"17/07/2026".
Two separate causes, both fixed here:
The date was never formatted in the UI at all. listVaultEntries() ran
DATE_FORMAT(created_at, '%d/%m/%Y') in SQL, so the app just printed a
string the server had already baked into UK/EU order - unreachable from
the client and contradicting the Region the settings page claims. It now
selects UNIX_TIMESTAMP(created_at) and the UI formats it via a new
formatMediumDate() in lib/time.ts, which uses getLocaleTag() like the
other shared date helpers.
createdis typed number (seconds) and thedev mocks were moved onto real timestamps.
The Settings row it was compared against was itself a hardcoded string,
so it could never agree with anything. It now renders through the same
helper.
Verified across the shipped locales: the reported 17/07/2026 renders as
"July 17, 2026" (en-US), "17 July 2026" (en-GB), "17 juillet 2026" (fr-FR).
Unparseable/missing values return '' and the row hides, as before.
Fixes #21