Date format is incorrect in 1Password for Mac
Comments
-
Hello everyone,
The development team is working on a complete overhaul of how dates are handled in the app as a whole but that work will take time since we want to make sure that we get it right.
Fixes included in previous updates to 1Password have improved the situation considerably for many but there are certain cases where localization is still not working as it should be. Specifically, if you're using a region that differs from the language selected. For example:
- Region:
United Kingdom - Preferred language:
English (US)
Although the region is set to the United Kingdom, 1Password displays the date format as if the region was set to the United States. This is due to language and region not being clearly separated. A workaround is to change your language to the region that includes the date format that you'd like to use. So, if you wanted to use the DD/MM/YY format used in the UK you would set your preferred language in macOS to
English (UK).This suggestion isn't going to work for everyone since some folks require a specific regional language that differs from their geographic region. Our development team is actively working on a proper solution. But I wanted to mention the workaround again for those who were new to the thread.
As mentioned, our developers are working on a complete refactor of the code that handles the rendering of dates/times. Not only will this refactor improve 1Password in many areas, and allow for better date rendering in general, but the refactored code will allow 1Password to correctly display dates/times according to the region set in macOS and will resolve the issue reported in this thread for all users and all regions. The team's focus is on getting this new date/time rendering system developed and released. While I'm unable to say which update will include the overhaul, our developers continue to be aware of the importance of getting date regions correct.
I know that this issue has been affecting some folks for quite some time and I'm sorry for the continued impact to your workflows. Your feedback and frustration regarding this issue is heard by the entire team. We appreciate everyone’s patience and understanding as we continue to work to develop and release a solution that will resolve the issue for everyone.
-Dave
6 - Region:
-
I just encountered this issue for the first time and raised a support issue. This issue seems like it’s common to all Electron-based apps... I’ve yet to encounter a single one that handles date/times correctly.
I’m wondering if it’s related to this bug, one that was raised 6yrs ago: https://github.com/electron/electron/issues/13023#issuecomment-418581463
0 -
After changing my primary language from 'English' to 'English (UK)' (region Netherlands) in MacOS System Settings, I can confirm the date representation changed from 'American' to 'British'.
3 -
Good find @paulgrav
Perhaps 1Password devs could fix the Electron bug and fix a bunch of apps? That's supposed to be benefit and the beauty of Open Source software.
1 -
@Dave_1P I just noticed that the release notes for 8.10.28 for both macOS and Windows state:
"The language and date formatting for item creation and modification dates now respect your operating system’s locale settings."
They still don't. I see no change in behavior on both macOS and Windows. Both systems are set to English (US) and locale is set to German:
macOS 14.4:
Windows 11 Pro 23H2:
2 -
I don’t understand this, why is the team looking to have date as per the system only? Just ask it to pickup details and show your format with all possible options? On my Mac if I choose India then I don’t get format DDMMMYYYY. This is what I want to avoid any kind of confusion or error with date. The month has to be in words only.
0 -
@fok and @vishalsheth
I'm sorry for the confusion, I've flagged this to the team and the release note has been updated:
Created and modified dates for items are now formatted according to your operating system’s language settings and standards specified by the Unicode Consortium.
This is part of the work being done by our development team to improve how dates are handled in 1Password but there is more work to be done. Thank you for pinging me so that we could get the note corrected.
-Dave
0 -
My passport expiry dates reverted to the wrong format in iOS, again.
It’s currently too dangerous for me to use 1Pass for storing/retrieving my passport data. If 1Pass is having such trouble reliably retrieving system preferences then why not have an override in 1Pass settings where I can explicitly set YYYY-MM-DD?
Perhaps I, the user, should stop using date/time field types and covert the fields to text?
0 -
@Dave_1P, the new wording is even more confusing now as it's unclear whether "your operating system's language settings" includes regional/locale formatting settings or not. I think most users would assume so, but it seems like in this case it's not.
If I understand you correctly, the development team acknowledges that currently date/time formatting is wrongly derived from the interface language of the operating system, cleared some stuff up internally in 8.10.28, and will fix this in a future release by adopting the regional/locale formatting settings of the operating system?
0 -
It's also still broken for macOS 14.3.1. My passport dates are still displayed in US format, despite my system settings. Sigh. Hard to believe that this problem has persisted so long.
0 -
why are we relying on the system date format? Why can't 1password give the formats directly?
0 -
Hello folks,
The change in version 8.10.28 is part of our development team's larger efforts to improve how dates are handled in the 1Password apps on all platforms. This particular update only applies these changes to created and modified dates as noted in the release notes:
Created and modified dates for items are now formatted according to your operating system’s language settings and standards specified by the Unicode Consortium.
The issue to fix date formatting for things like Passport item expiry dates is still open with our development team.
-Dave
0 -
When I'm viewing a card the date format is MM/DD/YY. When I edit the same, it is DD/MM/YYYY. Why? This is on Mac.
On iPhone it's viewing a card the date format is MM/DD/YY. When I edit the same, it is DD MMM YYYY.
On Android it's viewing a card the date format is YYYY-MM-DD. When I edit the same, it is DD/MM/YYYY.
I fail to understand this different formats on different operating systems.
1 -
Confirming the issue in Mac OS. Date is set to DD.MM.YYYY, 1pass shows as MM.DD.YY.
0 -
@Dave_1P I understand the team efforts to handle dates but an option in setting might help. Some prefer DDMMYYYY while others might prefer DDMMMYYYY or MMDDYYYY. Similarly, for time it may be OK for some to use 12hr and others will prefer 24hr. It should take system setting but if not then user should be able to override in settings. It helps if people move to other country for work or have personal preference as well as keep it consistent across platforms.
3 -
Also, it would be perfect to align all dates with the same format (for example the short one on macOS), instead of having 1 format for passkey date, 1 another format for field date, 1 another format for created date... Example:
1 -
Thanks everyone, I've passed all of your comments and reports to the team. Thank you for hanging in there while the team continues the work to bring complete consistency to dates in 1Password 8.
-Dave
0 -
After changing my language to English (UK) the date format is fixed. Finally!
0 -
How can this still be an issue in 2024?
Electron
Oh. Right. 🤦
0 -
Wow! It works! Even without changing my language to English (UK). Hooray!
0 -
@sema, you mean changing system language, right? I can also change languages in 1Password itself, but there is no "English (UK)", and changing that to German or Spanish for example doesn't change anything.
However changing the system language is not a fix, it just shows what the bug is all about: System language should have no effect on date and time formats. That's what local/region settings are for.
Changing system language from English (US) to English (UK) is not something I want to do, as it has other undesired effects, e.g. renaming "Trash" to "Bin", ...
1
