24 Clock
In some “foreign” countries, people use a 24 hour clock instead of AM/PM
In 24 hour dates I was told to post here
Yes, on your Android phone you will find such a setting.
See also
DateFormat | API reference | Android Developers and please also allow people with the US locale to still choose 24h format if they want.
This is also an issue with the Extension on Windows 11.
Even with locale set to 24h clock and ISO date format (2024-11-12)
Bitwarden writes it backwards
The vast majority of countries use a 24 hour clock so this should be the default instead of the other way around.
Operating systems already have locale settings, which defines how dates, numbers (commas vs periods), etc. are formatted.
Is there a reason Bitwarden needs its own locale settings, or would this be better framed as a bug, reporting those place(s) where Bitwarden is displaying dates that without applying the OS’s locale setting?
Bugs can be reported either through the “bugs” link in the community’s blue menu bar, or you can open a case though Bitwarden support.
Well @jidanni was told by @sj-bitwarden to make a Feature request.
But it’s hard to frame something as a bug when the developers are US based and they are the backwards country using feet, AM/PM and backwards date formats.
Please could the rest of the World have the option to have the 24h clock. I appreciate that the US is the home of Bitwarden and the US have some quaint units, spellings and formats.
@TealOak Welcome to the forum!
I moved your post into this existing feature request to the same topic.
Today, I was wondering, whether the passkey “Created 02/09/2024” is from February or September. To get around this, I usually configure everything to ISO8601, which would be 2024-09-02. Ideally, the browser extension would follow the system locale to resolve this.
Contrary to 24 Hour clock in addition to AM/PM, I see the time in 24h format, so I think there might be some movement already.
I found this feature request while searching for any existing discussions about a similar issue with the Android app (it shows “last update” and “last sync” in a fixed American format, ignoring the system locale). This issue with Passkeys seems to be more of the same.
I’d actually consider this and any other similar mishandling of date formats to be a bug rather than a feature request. It really isn’t acceptable to use the American format anywhere other than on a device that has been set to an American locale - in the eyes of everywhere else in the world, it’s a strange half-reversed format that is almost impossible to parse!
There are several GitHub issues on the topic, as well as comments here in the forums. Would the Bitwarden devs be able to give us an update, and hopefully an ETA for this widespread problem to be fixed system-wide? Provided dates always follow the system locale, it’s less critical for them to be configurable, though that would be great if it’s easy. If for some reason it really has to be a fixed format, ISO8601 is the only viable option.
Thanks!
I support this BUG REPORT fully
How can Autofill work universally if parts of the system are blind to the locale setting of the system they are working with.
I’m a BitWarden newbie migrating from LastPass. on UK Windows desktop + Android mobile.
Until now I’ve been able to find my way through the jungle of Google, MS Authenticator and LastPass all fighting to be “top dog”.
Thanks to Bitwarden articles, I’ve managed the swap so far
But I’m very disappointed at such a basic omission as being aware of Regional settings
Please treat this as a usability bug, give it some priority, and report back here. Yes, we’re real people too!!
For the record, bug reports are tracked on Github, not here. To create a bug report, click “new issue” on Github.
I’m not a coder - at least not in current development languages
But I do want to help and to support constructive suggestions.
I see problems logged here going back to 2021 to do with date formats
and more recent problems logged 2024-2025 from international English users like me
This user forum is for people like me (I assume)
I hope that moderators will spot constructive suggestions,
point users towards help topics,
and pass good suggestions on to developers
AND feedback too.
Dates have varying regional formats.
I thought Bitwarden is a mature product with a good reputation.
Surely this is a serious omission???
I hope I’m not being unreasonable in such expectations
Spilly80
PS I did get a GitHub account before posting this reply
There are already several issues raised in GitHub, with varying degrees of acknowledgement - but no actual progress on any of them.
This really is a basic usability issue, which should have far higher priority for development time than the cosmetic changes which seem to form the bulk of recent updates (many of which are seriously negative changes in themselves, but that’s a different topic!).
I really want to support Bitwarden, as in most respects it’s far better than all of the other options out there. But this is one of a small number of issues which unfortunately gives the impression that priorities aren’t fully aligned with the needs of the users.
The reason we suggest posting yourself is not just so the observation gets the proper attention by the people best positioned to act on it, but also so any questions would be addressed to you instead of me which does nobody any good.
Do keep in mind that the moderators of this community forum (@grb, @Nail1684 and @DenBesten) are volunteers with no more access inside Bitwarden than any other customer. The community is primarily is a peer-to-peer venue with only occasional employee oversight.
I don’t speak for Bitwarden, but I know from experience submitting and reading bug reports on Github that Bitwarden would not consider this to be a bug. The date displays are functioning as intended/designed, and it would be accepted by Bitwarden devs as a bug report only if the displays did not function as intended/designed (e.g., if you see a date in the format 44/0\123 or Feb. 33, 19).
What you are asking for, is for the Bitwarden apps to be redesigned with the intent of honoring system locale settings for date/time formats (or at a minimum, to adhere to some international standard), instead of using a US-centric format. This would be a feature request for new/improved functionality.
If you don’t trust my experience with how Bitwarden handles bug reports, then I would suggest that you file your own bug report to see how it fares. To file a bug report, click the New Issue button on the github.com/bitwarden/clients/issues page.
Regardless, why split hairs about classification? As a feature request, the proposed functionality has considerable merit. I would suggest that you articulate those merits, instead of debating whether the required development work falls under the umbrella of bug fix vs. new feature.
Hmmm… I totally agree with @grb.
On the other hand, I think, in part it could be reported as a bug. Because at the bottom of any vault item (“View”), in the “item history”, the date is already formatted as:
It could be argued as an inconsistency in the UI/UX, which it indeed is, when passkeys are still formatted as (screenshot from my browser extension):
(and my impression at the moment is, BW wants to have a consistent UI/UX themselves, and so far, they are open to reports regarding that…)
So, if Jun 6, 2025 would be an acceptable improvement (for now) for the passkey field (which OP referenced), I think a bug report should be tried. – Of course, this wouldn’t bring a completely regional customizable date format, so this Feature Request still has merits, I think!
An even better variation that would require only minimal code revisions would be the dd mmm yyyy (e.g., 6 Jun 2025, or 06 JUN 2025) format used in email messages (RFC 5322 Section 3.3), in the US military, and even in some European standards.
Or 2025-12-25, which is sortable (although unneeded here), is pretty much universally unambiguous and does not really favor any given nation’s standard.
Yes this would be preferable, as it is the ISO 8601 standard, but the amount of code revision to implement this in the item history datestamps would be slightly greater than the revisions required to change Mar. 1, 2023 into 01 Mar 2023.
I genuinely believe this is a serious Usability issue that should be raised with the developers. I’m surprised that such an advanced product as BW didn’t iron this out long ago.
My own background is Excel and Visual Basic. In Excel you soon realise the issues on date-times, especially mandatory literals like #mm/dd/yyyy# required regardless of which region you live in. An ISO format is unambiguous in all western languages.
Action: I suggest someone more experienced than I raise a new GitHub Usability issue.
Any volunteers??
I’d like to see a standard internal date/time in ISO format with both input and Autofill output being interpreted by the client’s own regional settings.
The current Autofill function must already be aware of at least the title of target field properties.
Credit card Autofill is a bit more specialist. Data items such as Cr Card expiry destinations might be populated according to any ghosted YY, YYYY, mm, MMM etc.
