Wrong date/time format MacOS 12.3
when viewing an item in 1Password, at the bottom of the right hand panel that shows the details of the item, the date format does not match the system date format.
My system is set to dd/mm/yyyy
but 1Password is displaying dates at mm/dd/yyyy
This date/time should respect the regional date/time setting of the OS.
1Password for Mac 8.7.0
80700028, on BETA channel
1Password Version: 8.7.0
Extension Version: 2.3.1
OS Version: macOS 12.3
Referrer: forum-search:wrong date/time
Comments
-
Hey @Benno42:
Thanks for reaching out about this. This is something we're absolutely aware of, and hope to make improvements on in the future. I've added your feedback to our internal issue on dates not being localized, and we'll be sure to follow up with you as soon as we're able to share any improvements.
Jack
ref: dev/core/core#8747
0 -
Thanks Jack
0 -
Hello Jack,
Thanks for the details!
I understand that this is a beta, and therefore it comes with bugs or missing features here and there — but I do admit that I find myself a little bit disappointed by this issue, especially when Agile Bits has users all around the world, none of which use the US date format.
There are worst problems though, I'll admit, but I would hope that this issue is addressed before the full release :-)
@Jack.P_1P Are you at all at liberty to share an ETA for a fix regarding this issue? Even if approximate or tentative — I totally understand that it's hard to commit to specific dates.
If not, can you at least confirm whether this issue is considered important enough to be fixed before the public release? (I hope it is!)Thank you very much!
0 -
Hi @thibaultml, I'm sorry that we don't have anything to share on this at the moment - but we do appreciate your feedback on this and promise we're paying attention. Thanks for letting us know that this matters to you!
ref: dev/core/core#8747
0 -
@PeterG_1P Thank you very much for the prompt response, I genuinely appreciate it, despite my oncoming rant :-)
The fact that there isn't anything to share doesn't really make me confident nor hopeful that this issue would be addressed any time soon, which I find very disappointing. I expected Agile Bits, a Canadian company, to understand the importance for its international user base of a non-US-centric approach to software development. Especially more so when previous versions of 1P did not have this issue, and when operating systems (like macOS) have super easy-to-use APIs to address the issue very quickly.
I can't speak to the current web-based version, but I'd be really surprised if addressing such an issue took more than 2 engineer days to address on a native app (and I'm being very generous here), which would make it a high-value, quick win. But this is a web app, so it's I can't really pronounce myself.
I understand that neither you nor @Jack.P_1P are personally responsible for such a delay in getting this addressed, and I am not trying to be disrespectful. I love 1P overall. But I cannot help but be underwhelmed that this is not considered an issue important enough to address sooner rather than later.
Thank you however to both of you for acknowledging that the feedback is being received, listened to, and hopefully collected & collated to help prioritise items on the roadmap. And thank you for remaining polite when demanding users — like me — complain about issues they're passionate about. I know first hand how difficult that can be.
0 -
Hi @thibaultml, thanks for the thoughtful reply.
Thank you however to both of you for acknowledging that the feedback is being received, listened to, and hopefully collected & collated to help prioritise items on the roadmap. And thank you for remaining polite when demanding users — like me — complain about issues they're passionate about. I know first hand how difficult that can be.
I especially appreciate this! And likewise - thanks for the constructive discussion. We get a lot from this process, and especially when folks are courteous and passionate (as you are), we find that we're able to better inform our efforts to achieve genuine excellence. We care a lot about what we do - and we ask for your feedback! - so it's never a problem that you have a point of view on what matters, and what we're doing well, and where we may be coming up short.
The fact that there isn't anything to share doesn't really make me confident nor hopeful that this issue would be addressed any time soon, which I find very disappointing.
That's really understandable. We're somewhat limited, by design, on what we share about features and improvements that are coming through the production process (as well as features which might be implemented at some point, but about which we either haven't decided yet whether to do it, or haven't begun work on it). Among other reasons, this is so that we don't promise things we can't deliver, suggest that a certain feature will show up in one form when it ultimately emerges in another, and so on. And to speak only for myself, even if it weren't a matter of policy I'd personally be hesitant to share certain commitments because I'm not the one who has to design and build the thing. So I want to be conscious of my colleagues' workloads, existing commitments, priorities, deadlines, triage process, surprises that appear at the worst possible moment, and so on.
Sometimes improvements are a matter of "we can get this done in 48 hours, let's just do it and help out the sub-set of affected customers", but often things that appear simple may not be. I can't speak to the particular complexity of this one, but I'll follow up with the development team to better understand the issue as we're taking customer feedback. 👍
I expected Agile Bits, a Canadian company, to understand the importance for its international user base of a non-US-centric approach to software development.
We definitely understand that a global perspective is important - even though this has resulted in design choices that we've taken some criticism for recently. We'll keep trying to find the balance between a general approach that works for everyone, as well as appropriate localizations that make the app feel natural to your locale.
In regards to the regional date question: I'd love to know if this poses a particular problem for your workflow, or in what way it interferes with your app experience. This is a genuine question, not a challenge - and if we can highlight some specifics about it that are particularly troublesome, I can pass that on to our development team, and that will get rolled into the consideration of what happens when. Again, I can't promise anything in particular in terms of a timeline (and understand why that might be frustrating), but we really are tracking the feedback here very closely and doing our best to alleviate the pain points and roll out the cool new features on a schedule that makes sense. And I'd like to make sure that your needs and your use case are well-represented as we're progressing.
Thanks for your understanding - and your comments are truly well-taken!
0 -
I've just noticed this date issue with the modified and created text at the bottom of each item:
I look at this and it looks as though it was modified and created on 4th October 2022 - which is in the future.
Although it requires extra thought (i.e. "Hang on, it's not October yet - oh right, it must mean 10th April, not 4th October") for that date I can tell it's wrong, but if the date was 4/1/2022, how do I know that it's supposed to be 1st April not 4th January if it doesn't stick to any specified format?
It's also not consistent with the date fields added to the item itself. Those are in the correct format for my country. i.e. dd/mm/yyyy so obviously the code does exist in 1PW to format dates correctly as its used elsewhere.
However, even the formatting of the dates is inconsistent. In the date field the month number is two digits (04) whereas in the created text it is 1 digit.
It's also inconsistent (again and differently) with the way the modified and created are shown in the web interface:
It's like the teams writing these various elements of the 1PW app and web UI don't talk to each other to define a few standards before starting work. Even the modified label is different!
It can't even be argued that the format used in the modified and created text is the format used by most people, since pretty much only the USA puts the month before the day. See: https://en.wikipedia.org/wiki/Date_format_by_country
I'd love to know if this poses a particular problem for your workflow, or in what way it interferes with your app experience.
For me it is unnecessary friction and often confusion and I hate inconsistencies. Rather than the date format being the same everywhere and what I expect for my location, I have to consciously consider (and try to remember) which way round the particular date I'm looking at is, and if I remember it's the wrong way round, I have to mentally swap the digits around to process it further.
Even if the modified and created dates showed the month in short or long text form (Oct or October) it would help, as I'd instantly be able to determine what the date is for those ambiguous dates where the day is 12 or less.
For example: 4/10/2022 shown as April 10 2022
0 -
For passport (or other) records, I think it would be good to have either ISO 8601 (YYYY-MM-DD) format or user-selectable format, or maybe sync with the system format. (E.g. on my Mac, I have set the system date format to be ISO 8601.) User-selectable or a preset should include a date format with month names, full or abbreviated, e.g. Mar 04, 2022.
1Password Version: 8.7.0
Extension Version: Not Provided
OS Version: macOS 10.15.7
Referrer: forum-search:date format0 -
Hi @whoopingcrane:
Thanks for your feedback on this! We've recently made some improvements to the date fields in items (like an expiration date for a passport), and it should now respect your preferred date format as of version 8.7.1. Let me know if that's improved your state of play, or if you're still seeing places where your preferred date format isn't used!
Jack
0 -
Has there been any progress on this issue in the last 3 months? 80800215 BETA still shows the incorrect and inconsistent date formatting for the modified and created labels.
0 -
Is there any development on a proper date format ? dd//mm/yyyy
0 -
It's rather disappointing there's been no update on this for almost 4 months, and no (visible) changes in the app, for an issue that affects the "majority of the world's countries"
0 -
It's really disappointing that this still isn't fixed.
0 -
6 months on, and still no change, and 5 months since the last response from anyone at AgileBits.
Can't we even get a "it's still being worked on" response? (Although I don't see how changing the output format of 2 dates takes over 6 months in JavaScript, even though there's been some date issues in Electron).
0 -
This issue is now fixed in the latest nightly release (80910025). Thanks all.
0 -
@Jack.P_1P sorry to resurrect an old thread, I'm still seeing some date format mis-match in 1Password for Windows 8.9.10. I've included a screenshot to show the issue: my system date format is dd/MM/yyyy, but the modified/created on dates on items are showing as MM/dd/yyyy. You'll see the update check date on the about screen is correctly dd/MM though!
(Please don't be confused by the "ENG US" language bar. My region is set to UK but I use an ANSI (US) keyboard layout)
0 -
Hey @nimro:
Thanks for bringing this up again. While I don't have any timelines to share on when these changes will make it to the beta or production channel, what I can tell you is we've made some improvements to date formats for the modified and created fields, and those changes are available in the nightly channel. 😀
If you'd like to give the nightly channel a try, choose Settings > Advanced, then change the release channel selector to Nightly.
Jack
0 -
Hello. I wanted to create a thread about 1Password 8 not using date format set on macOS, but figured that there are multiple thread about this already, some of them go back to 2021 and are closed already.
I am on 1Password 8 only since v8.10 and all dates in 1Password MM/DD/YY format, when in Language & Region settings on macOS it is DD.MM.YYYY.
Looking forward for this being fixed too.
*Currently on macOS Ventura 13.3.1 and 1Password 8.10.3.
0 -
This doesn't seem to be fixed on the nightly release for macOS. 1Password doesn't respect the date format set in my operating system and instead has day and month in the wrong order.
0 -
Thank you for reporting the issue. Our developers have completed some foundational work on addressing data localization issues which was included in the 8.9.12 update to 1Password but there is still more work to be done. I've added your reports to the internal work item that we have open for the issue. I'm sorry for the inconvenience that the issue is causing.
-Dave
ref: dev/core/core#8747
0
