Perhaps use a format like 3/Nov/2021?
Maybe it's just Croatian that's ruining it for everyone.
Around this part of the world, almost everyone calls tea by some variation of the word "chai". But not us. In Polish, it's herbata!
(And in general case, of electronic documents with wider audience, using 3/Nov/2021 excludes people who don't know English (or the language in which you encoded the name of the month).)
(Real use case: I recently sent a Polish equivalent of OSHA form to my line manager in UK, and I used a bilingual version. As you can imagine, I set the example by filling my part of the document using ISO 8601 for dates, so that once the document returns to the Polish corporate office, there won't be any possible confusions.)
People were unfamiliar with showering and brushing their teeth. We move forward.
On government forms (and other paper forms), I use 3/11/2021. It's unambiguous; nobody would expect it to mean anything other than "3rd of November of 2021". The ambiguity only happens once you add the Internet to the mix, and even then, only in English-language websites (I wouldn't expect anything other than DD/MM/YYYY on Portuguese-language websites, and the same probably applies to most other languages).
In a globalized economy, local date formats are just one of those annoyances that serve no benefit, cause everyone unnecessary hassle, occasionally causes expensive errors, and that should have long ago been replaced with an international standard.
What developers also suck at, in practice, is data-typing their output properly. If I see 5/2/11 on a US site while using my work laptop, I can't be sure whether it's the US notation written by the author, or date localized by my browser for UK format, which has the day and month reversed. I can't tell if the date is localized or not, or how it was generated.
Just say no to all that complexity, and use ISO 8601 everywhere. My controversial view here is: in this industry, we're still in a privileged position to force the entire world to standardize on the important things, like dates and times. So let's do so, and get everyone on board with an international standard, instead of just unwittingly pushing the USA defaults. We are pushing things, that comes with "software eating the world". So let's push things that make sense.
Also, should you want to change the locale (via a preference or override somehow), in most browsers you can pass it as the first parameter.
I think your view is very much a classic developers view - sure it would be nice to be able to dictate software requirements to businesses but you are probably going to be quite angry as your version of right and someone else's are going to be different.
There are absolutely no usecases where the US date format makes sense. No, having it written in the order you prefer to pronounce it is not an argument. Especially not in the language where you have to learn spelling. It is just what US people are used to.
The thing is, we sort of are! As I mentioned upthread, notation and language are being strongly influenced by increased use of software in every facet of our lives. The way people note numbers, dates, express search terms, etc. are all impacted by what the software accepts and displays by default. We have an opportunity here to push for positive cultural change around international standardization, so let's make good use of it, instead of squandering it by just implementing whatever seems to resemble the local status quo the most.
3/11/2021
3/11/2021
The difference is one was formatted incorrectly, and the other was formatted correctly. One is 2021-03-11, the other is 2021-11-03.Even having been told that there's a difference, you cannot know which is which.
Even if you think you know because you found an unambigious date like 31/11/2021 somewhere, you still shouldn't be confident because there are many sources of dates, and they're formatted by many different pieces of code. Some may be doing the "right" thing, some may be using US formatting. A complex web application like the Azure or AWS consoles might have literally thousands of sources of dates formatted by a thousand different pieces of code.
Before the 12th of the month, they're all totally and utterly useless for 96% of the world unless they use ISO 8601.
BTW: I just tested this with the Azure portal by clicking through some Log Analytics related things. I got it to show me 3 different date formats, 2 of which would have been ambiguous earlier in the month, and one of which changed between two tenants. So even if you learn which parts of the UI you can trust to be correct, switching tenants will invalidate your experience.
I’ve scheduled cron jobs for February 31st, to have them tracked but disabled.
users who don't know what ISO 8601 is would learn, simply because when that format is used in software, it is consistent!
Wikipedia claims [0] that is the date format in Kazakhstan, but only for the Kazakh language, not for Russian. (Maybe there is someone here from Kazakhstan who can confirm if that is true or not.)
A lot of companies don't have any employees in Kazakhstan (which means they can ignore this for internal systems); and many companies wouldn't have any customers there either (which means they can ignore it for external systems as well).
That doesn't seem like a standard API call.
https://developer.mozilla.org/docs/Web/JavaScript/Reference/...
Your code has a bug, missing constructor.
sigh.
ISO 8601 everything. I'm religious about it. I write it in messages, on government forms, anything that doesn't force me to use a different format. On a bit of my insistence, we use ISO 8601 notation for all dates at home. I think the benefit is quite obvious once one starts using it.