Forum Discussion

pepijnve's avatar
pepijnve
New Contributor
3 months ago
Solved

Date field format does not match system settings

In the macOS client, I was just entering the details for a new item and notice the date fields are using mm/dd/yyyy as template.  The macOS system settings are set to dd/mm/yyyy. This incon...
macos
  • 1P_Dave's avatar
    1P_Dave
    3 months ago

    Hello pepijnve! 👋

    I'm sorry that 1Password for Mac doesn't match the date format that you have set for macOS itself when editing an item. This is a known issue that our development team is aware of and is working on a fix for. 

    Keep an eye on our release notes which will mention a fix as soon as it is released: https://releases.1password.com/

    -Dave

muonzoo's avatar
muonzoo
New Contributor
3 months ago

I'm not sure why this is marked as solved as I live in a locale that uses DD-MM-YYYY; but I set my OS to YYYY-MM-DD (because that's the CORRECT way to format dates - I'm opinionated that way, but ISO8601 is a common way to deal with this). I really don't understand why I see dates formatted in ways that I don't want or use anywhere in my system.  Please prioritise fixing this,  it isn't just a preference but errors get made and then there are consequences. My child's passport application was held up because of this bug (month and date transposed led to secondary questioning). Again - this isn't a cutesy thing but a real operability bug. As a 10+ year customer I really really want to see this fixed. The whole world isn't using the same date system and that the ISO standard isn't working correctly is a bit of a shocker to me after all these years. Sorry that I'm venting; but this isn't just a preference - it causes people problems.

  • 1P_Dave's avatar
    1P_Dave
    Icon for Moderator rankModerator
    14 days ago

    ​ muonzoo​ 

    I'm sorry for the impact that this issue has caused. 1Password should respect your system date format and this is a known issue that our development team is working to resolve in a future update. 

    -Dave

    • muonzoo's avatar
      muonzoo
      New Contributor
      14 days ago

      Thanks for the response. I'm not sure that I reported another subtle and dangerous bug: dates appear in iso8601 as per my locale setting but when I hit edit it quickly reverts to something else mm/dd/yyyy or dd/mm/yyyy. Which causes data entry errors as I need to notice and transpose. 

      apologies if this is documented elsewhere but I'm on mobile today. 

      • 1P_Dave's avatar
        1P_Dave
        Icon for Moderator rankModerator
        8 days ago

        muonzoo 

        Thank you for the report, I can confirm that seeing a different date format when viewing an item and editing an item is also a known issue that can occur for certain system regions and date formats. Our developers are working to resolve the issue and I've added your report to the internal work item open with the team, I'm sorry for the confusion.

        -Dave

  • pepijnve's avatar
    pepijnve
    New Contributor
    3 months ago

    FWIW, I did not mark this as a solution myself. I was a bit disappointed to hear that this has been a problem for quite some time. I’m a software developer myself. Date and time handling is not trivial in programming, but consistent formatting and parsing is really not the hard part. Correct handling of timezones, arithmetic taking leap seconds and such into account, etc. is.

    I agree with you muonzoo that this kind of bug makes using date fields quite error prone. To make matters worse, it’s not just that on input the field uses the wrong format. On display it does the use the correct one. So the entered value flips from one format to a different one. In the end you can’t really trust the software and have to double check every time.