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.
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...
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.
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.
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).
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.
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.
I 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 :)
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.
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 ...)
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?
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.
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.
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.
> 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.
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.
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.
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.
> 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
"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.
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”?
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.
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.
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.
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.
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).
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.
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.
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.
??/??/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).
So M is one of {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ↊, ↋}.
U+218A ↊ TURNED DIGIT TWO
U+218B ↋ TURNED DIGIT THREE
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. :-)
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.
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.
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?
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.
Sadly, my arguments that URLs should follow the same logic (instead of middle-out) and go something like:
.com.example.sub/path/to/folder/and/file.html
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).
Though of course I only use numbers in the name - no month name.
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.
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.
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!
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"
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.
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.
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!"
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.
118 comments
[ 2.6 ms ] story [ 217 ms ] threadAnecdotally, 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.
The full year is required to make it clear that 23-12-10 isn’t the day before X-mas eve in 2010
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).
And those changes may affect which "day" you consider something to have occurred on, date alone is frequently not good enough.
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.
> 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!)
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.
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 ...)
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?
So these are good.
- year / month / day
- day / month / year
And this is bad.
- month / day / year
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.
"May 3" / "May 3rd" or "3 May" ?
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
Why?
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.
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.
How does it make it easier and more useful?
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.
[1] https://en.m.wikipedia.org/wiki/Decimal_separator
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.
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.
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.
[1] https://strongboxsafe.com/
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.
https://secrets.app
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.
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.
My understanding is people want a format that machines and computers can read without introducing a translation layer.
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.
Edit: Good point, bashinator <3
Sure :)
But to their credit, @bpicolo makes a very valid point.
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.
October 15, 2023... octo... that must be... the 8th month!
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).
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. :-)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.
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.
Saying “No one would assume” is only reasonable if you decide to ignore how human beings behave.
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
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.
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.
Can you provide an example of a country/nation/population that uses YYYY-DD-MM as their standard date format?
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.
Though of course I only use numbers in the name - no month name.
01 JUN 2023
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 really need to back everything up offline more frequently.