Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
Former Member
3 years agoDate copy format.
When copying a day to paste in a field the copied text isn’t zero filled. Ie 6/5/2023. Often this isn’t accepted. Requires zero filling. 06/05/2023.
Former Member
3 years ago1P_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.