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

  • Jack.P_1PJack.P_1P

    Team Member

    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

  • Benno42Benno42
    Community Member

    Thanks Jack

  • Jack.P_1PJack.P_1P

    Team Member

    You're very welcome @Benno42!

    Jack

  • thibaultmlthibaultml
    Community Member
    edited April 12

    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!

  • PeterG_1PPeterG_1P

    Team Member
    edited April 12

    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

  • thibaultmlthibaultml
    Community Member

    @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.

  • PeterG_1PPeterG_1P

    Team Member

    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!

  • snozdopsnozdop
    Community Member
    edited April 23

    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

  • PeterG_1PPeterG_1P

    Team Member

    Hi @snozdop, thanks for the well-considered details here. I have passed your post along to the developers and look forward to following future updates regarding how this is handled. I'll make sure to share any relevant news in this thread as well.

    ref: dev/core/core#8747

  • snozdopsnozdop
    Community Member

    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.

  • srbharrisonsrbharrison Junior Member
    Community Member

    Is there any development on a proper date format ? dd//mm/yyyy

  • snozdopsnozdop
    Community Member

    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"

  • viswizviswiz
    Community Member

    It's really disappointing that this still isn't fixed.

  • snozdopsnozdop
    Community Member

    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).

  • ag_tommyag_tommy

    Team Member
    edited August 30

    @snozdop

    I just checked and the issue remains open on our end. I'm sorry I do not have an update.

    ref: dev/core/core#8747.

  • snozdopsnozdop
    Community Member

    This issue is now fixed in the latest nightly release (80910025). Thanks all.

  • BenBen AWS Team

    Team Member

    Thanks for sharing, @snozdop! 😄 Glad to hear the changes we're making have resolved this for you. Hopefully we can get that out in a stable release soon. 🤞

    Ben

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file