1Password 8 has been formatting dates incorrectly for over a year
1password.communityI can certainly echo the (HN) poster's comment from a few days ago:
> I am having trouble with the date formats on macOS. My passport expiry is shown in MM/DD/YYYY, even though my date locale is clearly set to DD.MM.YYYY. In 1Password 7, as far as I can tell, it used to be DD/MM/YYYY.
> I have literally had a ton of trouble because of this because I entered my passport expiry date wrong on an airline form. As both numbers in the date can be flipped and will still show a valid date, this error isn't easy to catch, either. After looking this up, it has been first reported over 1.5 years ago! That is not an acceptable timeframe!
I've already had some wrestling with incorrect date formatting in 1Password, but I recently added my family's passports and almost made the exact same mistake.
You could somewhat justify future support back when 1P 7.x was in support, but now that it's completely EOL (mobile app is unlisted), there's absolutely no reason for this. It's literally one system API call. (Which they're already using in the "modified/created" fields on iOS!)
I am happy to report that after my post on here a developer has reached out, and the issue is indeed fixed for me in the latest nightly build of 1Password. Seems like this issue can finally be wrapped up :)
The debate here over which date format is best is pointless, and has nothing to do with the problem reported here. Computers have locale settings. You can set the date format to your preferred or expected format. The issue is that 1Password isn't respecting that locale. This has literally nothing to do with whether the US is backwards or your own unique personal date coding is better.
I’ve been a happy user of 1 password for 5+ years, but I’m considering changing.
This goes beyond date format for me. Issues like these show that the company is not committed to listening to feedback and addressing issues. It erodes my trust in them. Given that they hold my passwords, trust is paramount.
Same with their decision of not adding 1 password 8 into the Mac App Store. I won’t install outside the App Store, so I’m sticking with 7. The moment that goes, so do I.
If you were starting from scratch today would you stick with 1Password or would you use Bitwarden or some other alternative?
I've been using 1Password since 2009 and I would suggest you try any and every alternative first before giving Agile Bits a dime.
Not the OP, but Proton Pass is probably where I'd look. (And am in fact looking as I inch closer to ditching 1Password.)
If you live with an Apple-only pw manager, I really like https://minimalistpassword.com . No separate account needed (syncs through iCloud), uses the system password autofill, no Safari extension or weird permissions.
Bitwarden is incredibly clunky IMO. Not worth it. Yes it is cheap, but you get what you pay for.
For a cross platform solution, I think KeePass-based pw managers are great. Create a database, set up sync however, and just us a KeePass-style app on each device. The beauty is that it's only the database that matters, so switching between apps is pretty painless, and they can't hold your data hostage.
What service/cloud provider would you use for cross platform? Dropbox is the obvious choice but the cheapest tier is 7.99 for 2tb nowadays.
Great q, probably google drive? Not sure how well the desktop app works for syncing these days
I've been wanting to spend more time trying out Strongbox[1], personally. It's only available for Apple (macOS, iOS, and iPadOS) devices, which rules out the 1% of the time I use an oddball Linux or Windows desktop, but it's a bit more reminiscent of old 1Password UIs with less of the dismissive attitude that I've gotten from 1Password's support team over the last couple years.
Strongbox uses the KeePass database format, so if you set up sync you can just use other KeePass-based apps on other devices.
I’ve been looking through a bunch in the last few years and keep going back to 1password mainly for browser integration. It’s add-on is simply better than most. And it’s the only one i know of that has a plugin for ios safari.
If you can live with Apple only, then Secrets is absolutely superb.
Hey HN!
Glad to have this reach the frontpage as 1Pass support has been unhelpful with this for months, so I‘m hoping to get some attention to this issue via this route.
My previous comment has already been quoted here, so I won‘t reiterate, but this issue is generally easy-to-fix, yet can have a huge impact if not working.
Very annoyed with 1Password’s product direction and support on this. Their customer focus has been off for a while in my eyes, sadly.
I've been holding out on 7 for reasons like this. The native macOS version seems to honour my system locale settings. I don't see myself moving to an Electron-based app, and am really hoping that the updated keychain stuff in Sonoma will be such that I can just say goodbye, despite how much I've enjoyed 1Password for the _many_ years I've been a loyal customer.
The part which I find so unfathomable is that the UI of 1Password isn't even that complicated, nor is it subject to rapid change. Maintaining three or four 100% native platform-specific front-end codebases seems entirely reasonable and trivial. Particularly given that customers are paying good money for this app!
I abandoned it as soon as they switched to Electron. I wouldn't mind if it was something I used it once a month but for an app that is running all the time the overhead is unacceptable to me.
What do you use? I know 1PW7's days are limited so I'm looking for an alternative but haven't found a good one yet.
KeePassXC
The responses from 1Password are maddening. "Can't say if of when the dev team will address this", "I'll add a vote on your behalf (smiley)", "Keep checking our release notes"
"We're moving to Electron so that we can iterate and ship features and fixes much faster". This is the same 1Password that hobbled keyboard navigation 2 versions ago and still hasn't fixed it.
The best date format, in my humble opinion:
yyyy-mm(mmm)-dd
2023-07(Jul)-12
...
Why?
- Goes from biggest to lowest value (year, then month, then day)
- To remove any ambiguation, also shows month in alpha format.
- Still sortable :-D This is the best part I think.
YYYY-MM-DD:
I don't like to put parentheses in filenames if I can avoid; may require shell escaping.- Unambiguous. - Actually sortable. - A standard (ISO-8601). - Still human-readable. - Is not tied to English.It’s not unambiguous. 2023-01-02 is as ambiguous as 01/02/2023 unless you’re a tech persona with precursor knowledge of date formats.
Edit: Good point, bashinator <3
I think it's definitely less ambiguous because there are no locales (that I know of) that use YYYY-DD-MM, whereas MM-DD-YYYY and DD-MM-YYYY are both quite common. So, with a little bit of experience, if you ever see four digits first you can be 99% sure that the next part of the date is the month.
Edit: I also think that you don't need to be involved in tech in any way to be aware of date formats. They show up in all kinds of everyday places like tax documents, bills, cheques, receipts, exams, etc.
For contexts where you want humans to understand and don't need lexical sorting (paper documents definitely fall into this category), you can make it super unambiguous – July 15, 2023. Can't mess it up.
Challenge accepted!
October 15, 2023... octo... that must be... the 8th month!
??/??/YYYY is ambiguous because ~3 billion people use DD/MM/YYYY whereas the US uses MM/DD/YYYY. Nobody (or very few) uses YYYY-DD-MM, so YYYY-MM-DD won't be confused with it.
Could say that there's still a small amount of ambiguity, but it's definitely not "as ambiguous as" ??/??/YYYY.
> unless you’re a tech persona with precursor knowledge of date formats
YYYY-MM-DD is the standard for billions of people. You don't need to be a tech persona to either use it or to understand the reasons for it (lack of ambiguity, consistency with other numbers).
Using duodecimal for the month will clear that remaining confusion right up, YYYY-M-DD.
Unicode has you covered!
https://en.wikipedia.org/wiki/Duodecimal
So M is one of {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ↊, ↋}.
There are other contenders for the 11th and 12th symbol, but all of those systems seem to assume counting from 0, which is... not a very fortunate choice: Human calendars generally numerate the first month as "1", not "0". So duodecimal does not get my vote for less ambiguity on either the account of determining what symbols to use, or where to start the sequence. :-)U+218A ↊ TURNED DIGIT TWO U+218B ↋ TURNED DIGIT THREE
Bad example; 01/01 is unambiguously Jan 1 no matter how you read it.
@bashinator
Sure :)
But to their credit, @bpicolo makes a very valid point.
- Unambiguous
The problem is that it is not unambiguous.
If you see 2023-03-02 in the wild there will be people who assume it is 3rd Feb.
Please correct me if I am wrong.
Can't resist that challenge :-)
You are wrong. Noone would assume YYYY-MM-DD would be YYYY-DD-MM. Why would they? Biggest, smaller, smallest unit. After that comes the time with Hour, Minute, Second. Again Biggest, smaller, smallest unit.
I mean, why would anyone have a problem with DD MM YYYY by the same reasoning? It’s smallest, bigger, biggest after all and yet the problem is well known.
Saying “No one would assume” is only reasonable if you decide to ignore how human beings behave.
Variants exists for MM/DD/YYYY and DD/MM/YYYY (medium, smallest, biggest). No variant exists for YYYY-MM-DD, nothing to confuse.
The international standard is pretty old by now, I learned it as a child.
When sorting, the year is most important. Instead of everything published on the first in each month ending up at the start of the list, you get everything published today at the top.
1/1/2039
1/1/2038
1/1/2002
1/2/1970
1/2/2025
I honestly don’t understand what you’re trying to say here. A variant does exist and it is YYYY-DD-MM. Is it a reasonable one? No. Do people in the real world only do reasonable things? Also no.
If you write “2023-02-03” you can be certain that a >0% of humans will read that as March 2 2023 because that’s what humans do.
And just to be clear, Where I live we do DD-MM-YYYY and as a dev I’m absolutely on board with YYYY-MM-DD.
> A variant does exist and it is YYYY-DD-MM.
But it’s not being used by anyone! It’s just a possible permutations, not in cultural use.
I could imagine two kinds of wrong reasoning that would lead to misinterpret YYYY-MM-DD:
An American who, in spite of being used to read dates aloud (05-01 = May 1st) decides that since the year comes first, the whole sequence is probably in reverse.
A European who, in spite of being used to a logical ordering, decided that since it unusually starts with the year, maybe it’s an American date.
I can imagine those mistakes being made.
I also think they are very unlikely to happen, and vastly less likely than Americans who read European dates and literally can’t tell, or vice versa.
The only widely used date format that does not have a competing interpretation is YYYY-MM-DD. For that reason alone, it is less ambiguous.
> I honestly don’t understand what you’re trying to say here. A variant does exist and it is YYYY-DD-MM. Is it a reasonable one? No. Do people in the real world only do reasonable things? Also no.
Can you provide an example of a country/nation/population that uses YYYY-DD-MM as their standard date format?
I've been using this for a lot of date display for all those reasons.
This is the way.
We're lucky enough that almost nobody is (yet) using yyyy-dd-mm, so fortunately ISO 8601 is still pretty unambiguous in the real world.
Yes, but in the wild, lay people can easily assume yyyy-dd-mm. See this: https://news.ycombinator.com/item?id=36699269
My claim is that almost nobody would jump to that interpretation because there is no pre-existing convention with year first and day and then month.
I guess if you'd never seen an ISO date before, and you were accustomed to DD-MM-YYYY, then it could still be ambiguous. It's all context dependent anyhow—who's to say 2023-07-13 is a date and not an arithmetic expression, or a code in some filing system that happens to look like a date.
I've been arguing this for decades. I'm glad to see that I'm not alone!
Is there any way to official present this format for review and adoption? Like an RFC or something?
I think it would have to be through ISO or similar, not the IETF. But I'm not sure.
Sadly, my arguments that URLs should follow the same logic (instead of middle-out) and go something like:
have yet to meet success. I suppose it's because the date format naming has a great immediate effect: sorting a folder by file gives you intended-time sorting as well (which may not match creation time if you copy or download the file)..com.example.sub/path/to/folder/and/file.htmlThough of course I only use numbers in the name - no month name.
This assumes the users speak English, which continues to dance around the problem of the format not matching the user's preference (language and date format).
> This assumes the users speak English
Where's the assumption? On the alpha portion? The date internally can be stored as it is, this is only the display and the alpha portion can be localized.
If you can customize the display based on the user's device, then we are back to the current problem of companies not customizing the display based on the user's device.
My understanding is people want a format that machines and computers can read without introducing a translation layer.
>the alpha portion can be localized
but can it? if you're putting dates in something like filenames or CSVs, then no, it can't be localized. you get one string, and that's it. if you're displaying a date in an app, then whatever platform you're targeting probably has some method to diplsay a localized date, and you should use it. but for anywhere that you have to choose a date format, that probably means you don't get to localize.
Time is a PITA to normalize between frontends and backends, but not an overly arduous task. I wonder what's preventing them from know what the users preferred format is.
Anecdotally, I worked for a British company that used YY/MM/DD and it regularly caused reliability issues during operations. Of course, they responded with, "What's wrong with the date? It's correct." Yes - correct, but not accessible especially operationally so. If you want to take advantage of a global userbase or workforce be prepared to have the tax of these kinds of features being necessary.
Email requires you to store something and it's perpetually buggy to infer, but with an interactive client the answer is pretty much always "store unix, localize at display-time on the device". Any other way means risking disagreement with the device settings, and that format is BY FAR what people expect when they use their device.
> store unix
Heck no. That means your date changes if the instant<->date mapping changes (for example, adding a leap second, or your country changes their time zones). If it's a plain date, store it as an ISO 8601 date (for example, "2023-12-30"), or equivalent plain date format (such as Postgres DATE).
No, leap seconds are included in Unix time, so adding leap seconds won't change how it's converted into a human-readable date. To store it without leap seconds you would use TAI time.
Anyway, sure, for scheduling something in a calendar you would want something timezone-aware. But not for storing timestamps. If a country changes what time zone they used it the past (not sure why they would ever do that) that shouldn't move the time the objective time an event occurred at.
Unix -> "include leap seconds and time zone changes" conversion is extremely well studied and well supported. Literally every major operating system does it as the primary way to display dates - that's what the time-zone database in ICU/CLDR exists to solve.
And those changes may affect which "day" you consider something to have occurred on, date alone is frequently not good enough.
Naturally they had problems if they wrote it YY/MM/DD. It's not a correct way of formatting the ISO 8601 date. It's supposed to be YY-MM-DD. If you use slashes between them it can be just about any format but if it's minuses it's YMD.
ISO 8601 specifies a 4-digit year for this reason. It's not YY-MM-DD, it's YYYY-MM-DD.
To be pedantic: YYYY-MM-DD
The full year is required to make it clear that 23-12-10 isn’t the day before X-mas eve in 2010
*YYYY
A slight improvement might have been to use four digits for the year. Then it’s a bit less likely to be interpreted ambiguously.
These days I display it as "12 July 2023" to avoid confusion.
How would that not be confusing to non-English speakers? Or even to English speakers when it inevitably gets truncated trying to fit "12 September 2023" in a field originally designed to show 6 or 8 digits...
The 1Password move to election has left it full of things like this that AgileBits then pretend aren’t real. I won’t be renewing my subscription now this is the only option.
I had 1Password gobble my GitHub account credentials, which is fucking terrifying since most of my 2fa backup codes get stored in 1Password.
I really need to back everything up offline more frequently.
Would love to know if and why it is hard to implement this kind of feature for 1P. Any takes?
Also there is a heated debate that the UK is doing dates "the right way" and the US is wrong. Other than that people from Europe seem to think all of their practices are better than others, what is the possible reasoning that the order of numbers in a date string could have a right and wrong solution?
> Other than that people from Europe seem to think all of their practices are better than others, what is the possible reasoning that the order of numbers in a date string could have a right and wrong solution?
The argument is that ordering the numbers based on the size of units makes things easier and more useful. Both DD-MM-YYYY and YYYY-MM-DD follow this pattern, and both have their advantages/disadvantages. The latter is especially useful due to alphanumerical sorting.
> ordering the numbers based on the size of units makes things easier and more useful
How does it make it easier and more useful?
Apart from sorting advantages it makes the format less confusing, since it's just about remembering ascending/descending vs. three individual positions. If I see a DD-MM-YYYY date or YYYY-MM-DD I know which one it has to be. If I see MM-DD-YYYY I have to be told, or I will misunderstand as long as the date is ambiguous.
Thank you for this comment and many others in this thread. I feel I've been converted to the YYYY-MM-DD structure. Because it's in order of specificity. It feels like it saves time and potentially compute.
However, I think a big problem with this is the way people say dates colloquially. Such as, March 24th 2019. Or even the 24th of March, 2019.
I can't imagine saying to someone, oh can you come over to my party, it's 2024 September 5th.
In many ways digital is designed to be a facsimile of analog. So sometimes what "makes sense" to people hyper fixated on the topic are simply not amenable to real society.
So that's where DD-MM-YYYY comes in. In my language people always say dates in that order, and even when taking English I'll refer to "the 24th of March 2019". YYYY-MM-DD is, strangely enough, kind of just "a bunch of numbers" to me. If someone tells me a date in that format it'll take a second to realise it's a date. But for digital storage it's highly useful! I'm fine switching between the two formats based on the situation. The length of the year specifier makes this unambiguous.
Big endian ordering reduces sorting by date to sorting by number. But not big endian parts in little endian order.
There is no correct answer. Having the segments go from smallest to largest or vice versa seems more logical than mid-small-large, but frankly iso8601 is clearly the most logical we have, but we’re never going to get everyone to use that outside of computer programming contexts.
Lexical sort ordering without parsing the date string is a great property.
But clearly in human terms it’s never going to be a solved issue! Nobody is looking for a solution, and everyone likes their own convention. Mutual understanding is what’s important.
The fact we have divergent date string formats is most frustrating because for many dates (up to the 12 of every month) it is ambiguous which format is in play.
It's not a matter of 1password deciding which format is "correct". They just need to actually respect the user's locale settings.
I agree, I was replying to the prior comment. Non-locale respecting dates are always problematic for users.
> Lexical sort ordering without parsing the date string is a great property.
Why? Why is the date even a string in the first place? It ought to be internally represented as 3 numbers. Or a Unix timestamp. Convert it to months, days, and/or years as appropriate right before printing.
Never use unix time stamp as date. You don’t know time zone, you need to calculate leap years (both days and seconds), summer time etc such a “date” would immediately morph into useless random number
The argument is that writing the parts in a consistently increasing or decreasing precision order makes more sense.
So these are good.
- year / month / day
- day / month / year
And this is bad.
- month / day / year
While I am a strong supporter of ISO8601 (e.g. 2023-07-12) there is an argument that decreasing specificity is preferable (as in ISO8601) and that for most day-to-day usage the year is somewhat implicit, hence being at the end.
Personally, I write the month out if I'm not using 8601 formatting to avoid any ambiguity.
For any sort of recordkeeping, though, I think it's preferable to go full on YYYY-MM-DD. It's more thorough, precise, and sorts properly on a computer.
Outside the US, how is a month+day combination written out/spoken?
"May 3" / "May 3rd" or "3 May" ?
In most contexts I would never use the cardinal number "3", it'd always be "the 3rd of May" or "May (the) 3rd", but in a country like Australia (with a high number of speakers from different cultural backgrounds) you hear all sorts of conventions used in casual conversation.
3 May in Italy. It’s always day first. You never hear anyone saying or writing the month first.
“3rd of may”
I don't think "it makes more sense" is exactly describing the reasoning.
Neither do I, but the rest of what I wrote does.
Doing a bunch of slashes like this is ambiguous. But the footgun that really worries me is the international divide over whether a decimal separator should be a comma or period. 10,000.00 or 10.000,00 [1] ! Which hasn't footguned me yet, but I'm just waiting for someone to complain about a 100x unexpected financial impact of whatever they bought, because it was only supposed to be 10.00 not 10,000. Yes, I know there's an extra zero there to rescue, but still.
Tech debt, a bunch of fundamental code that is hardcoded to process dates in the one format and would completely break everything if you passed it a date formatted otherwise. Dates are hard.
If for some reason you had to handle dates as strings everywhere and parse them yourself, then sure. But you should be able to pass and store Date objects or Unix timestamps internally, and then call established helpers to display them.
1Password 8 was a new code base.
Probably the fact that the US is the only country in the world that puts them the wrong way around.
I don't know why you're down voted.
Mm/DD/yyyy is a crazy format.
If it weren't for the fact that my month number and day number were the same, I don't think I ever would have gotten it right growing up
> Mm/DD/yyyy is a crazy format.
Why?
It's middle endian.
Imagine having middle endian values in a processor. You're reading "1,337" as 3317.
It's nonsensical.
Big-endian yyyy-mm-dd is the most rationally consistent since it's how we write numbers normally. 1,337 is big endian: the 1 is the most significant (biggest) number, etc.
Glad I've jumped ship to KeePassXC after 1PW7. The transition from 7->8 introduced nothing but bugs, electron bloat and lack of sensible data control to users, all of it sold by a tone-deaf PR department as "but written in rust!"
I wonder if this was a result of a PM treating localizacion as a feature that can be deprioritised to oblivion rather than a core deliverable of the feature “show a date”?
Why does a password manager even have major breaking changes?
Because it’s made by enterprise for enterprise, not by users for users
In the military, they force you to do dates as follows, which seems like the best idea to date.
01 JUN 2023
This not locale independent nor sortable.
Agreed. One of the better habits I picked up, I still automatically fill dates out like this.
Which military?
is anyone using 1Password 8? I thought everyone are still on 7
I expect that most users are on 1Password 8, if only because most users just auto-update and are blissfully unaware of any controversy—or just don't care. They do exist! Maybe they notice the regressions, maybe they rarely use the desktop app, maybe the regressions haven't hit them.
It's almost certainly a very vocal minority (of which I am a member) that is still on version 7.
(Funny thing was that some of the podcasters I listen to chided people quite derisively for being upset with 1P8. Fast-forward a year, those same podcasters are talking about how 1Password has sadly gone downhill ...)
I use 1Password 8 for my private stuff, and 7 for work, because... I don't know it's unclear if I can update.
The dates format formats correctly, I have a password I added a few days ago, says "modified 7.7.2023 15.59.44" ... and 5.7.2023 for the one before that. It's a little weird with the . but it's fine.
No complaints, it works perfectly well, much better than Lastpass ever did.
But was that previous one added 2 days before or 2 months before?
I just switched b/c it told me that the 7 browser plugin was going to stop working
Is anyone using 1password? I thought we were all using bitwarden/keepass....
Self-hosted, rust version, docker container?