Date copy format.

Thanks, Former Member. With the variety of different formats used by websites, I can understand that manually filling forms works better for you.

We're continuing to make improvements where possible and appreciate this additional insight about your workflow. 👍

1P_Gem
Since I don't really use 1Password for autofilling my identity data (or other non-credential data) often, that's not really an issue for me. I was just puzzled about the different date formats across browser extension and desktop app.

If it comes to my personal workflow, I type personal info into forms faster manually than autofilling and reworking the autofilled entries. It is often the case that autofilled fields are not accepted by websites and you have to edit the fields manually. Or entries have drop down lists that have to be used, even if they select exactly the same text that is autofilled. Or the form changes due to selected data. Or you need to enter street name and street number separately, while 1Password hasn't any extra field for the street number. Or telephone numbers are asked in international or local format, every website is different. So telephone numbers also don't work usually without editing.

In the end, entering everything manually in the first place is faster for me. Unmemorable data like IBAN can be filled separately with drag+drop from 1Password.

Hi @MikeRCol, thanks for getting back to me! I can confirm I'm seeing the same thing with Chrome set to English - dates are not shown or copied with leading zeros.

After discussing this with the team, it does seem as if this is the expected behaviour at the moment. However it definitely isn't ideal, so I have gone ahead and filed an internal issue for our developers to look into ways this could be improved.

Thanks to both of you for taking the time to report this issue 😄

ref: dev/core/core#22628

I’m using windows 10 chrome English.

1pw is not directly filling a field. I’m copying a m/d/yyyy field from 1pw and pasting into a web form on chrome. Would formatting the date as zero filled in 1pw pass through to the copy buffer solve the problem.

Hi Former Member! I've reached out to the wider team with the details of your case, to see if I can find out more information about this behaviour, and whether it's expected or something we could improve upon. Thanks for taking the time to test this in detail 😄

1P_Gem That's interesting. I just had "English" as language in Chrome. However, that's not possible to choose as language. I was able to choose "English (United States)" and "English (United Kingdom), so I again tried every combination. The same with German ("Deutsch"). Actually, you cannot choose "Deutsch" but only "Deutsch (Deutschland)" and other countries.

No matter the 1Password browser extension language, the date format was always according to the Chrome language.

This is what I got:
Chrome English: m/d/yyyy
Chrome English (United States): m/d/yyyy
Chrome English (United Kingdom) 0d/0m/yyyy (with leading 0 and d m in correct order!)
Chrome Deutsch: d.m.yyyy
Chrome Deutsch (Deutschland): d.m.yyyy

From all this, I deduct 1Password calls some Chrome API to get a localized date. Whatever Chrome is returning, 1Password is using this and doesn't create the localized date format itself.

I guess 1Password desktop app does the same, but instead calls some library/OS API for the date format, and that is returning with leading zero. In Windows, there are more detailed date formatting options, so I guess these are used by this API. Chrome seems to do its own localized date formatting, probably for returning the same value for all platforms, and this seems without leading zero for German. For English (UK) it does, but not for German.

This is programming hell: Localization, date+time formats, unicode characters (accented characters, Umlauts). After about 30 years of localization in IT products, it's still not done right.

Hi Former Member, thanks for these additional details, this is definitely very helpful! Were you using US or UK English?

1P_Gem This is not what I observe. Setting the Chrome UI language to English makes the date change from d.m.yyyy (German date format) to m/d/yyyy (Imperial date format: d and m wrong order). Changing the 1Password extension language doesn't change a thing for me. If I set it to German as well, and Chrome is English, date is still m/d/yyyy. Changing Chrome to German changes to d.m.yyyy.

Complete table:
Chrome English+Extension English: m/d/yyyy
Chrome English+Extension German: m/d/yyyy
Chrome German+Extension English: d.m.yyyy
Chrome German+Extension German: d.m.yyyy

In no case, 0d.0m.yyyy or 0m/0d/yyyy was displayed by the 1Password browser extension for me. Running "1Password in the browser 2.12.13 21201300, on NIGHTLY channel" and Chrome "Version 114.0.5735.199 (Offizieller Build) (64-Bit)".

In case it matters: my Windows 11 language is set to German, Windows regional settings are German as well. No other Windows langue is installed alongside with this. Since it is reasonably easy to switch Windows to arbitrary languages and regional settings, you should be able to work out if the Windows language/Windows regional settings matters here, or if it is a Chrome thing - my initiative to test out things come to an end here, unfortunately.

Hi Former Member, thanks for getting back to me! I've now been able to reproduce this behaviour with my browser set to German. Setting my browser back to English (UK) and leaving the 1Password extension set to German reverts the date to 0D/0M/YYYY, so this seems to be related to the browser's language setting specifically.

@MikeRCol, could you let us know what language your browser and the 1Password extension are set to as well, if it's different to Former Member?

1P_Gem Browser is Chrome, language is Deutsch (German) (browser itself as well as the 1Password extension).