News for hackers. Stuff that matters.
Re:ISO 8601: a better date format by TeMPOraL on Friday February 26, 2021 @03:49AM (#26272677)
Yup. I hate // AM/PM formats with a passion. Doesn't help that I work with UK teams now, and their "natural" date format is 3/11/2021, with meaning of 3 and 11 reversed to what they'd mean for Americans...

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.

Re:ISO 8601: a better date format by timvisee on Friday February 26, 2021 @07:09AM (#26273975)
Yes! I constantly get complaints when using ISO 8601 on school documents. But I won't stop using it.
Re:ISO 8601: a better date format by MaxBarraclough on Friday February 26, 2021 @07:16AM (#26274006)
I guess the complaints are because the format is unfamiliar and strikes non-software people as being non-standard.

Perhaps use a format like 3/Nov/2021?

Re:ISO 8601: a better date format by exporectomy on Friday February 26, 2021 @03:34PM (#26279543)
Can still be ambiguous because "list." means October in Croatian but November in Czech. Also, "lip." is July in Polish but June in Croatian and "srp." Is July in Croatian but August in Slovak.

Maybe it's just Croatian that's ruining it for everyone.

Re:ISO 8601: a better date format by TeMPOraL on Friday February 26, 2021 @05:54PM (#26280826)
I'm guessing every language ruins something for everyone else.

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!

Re:ISO 8601: a better date format by TeMPOraL on Friday February 26, 2021 @08:13AM (#26274399)
That's missing the point of pressuring the other side to adopt ISO 8601.

(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).)

Re:ISO 8601: a better date format by anoncake on Friday February 26, 2021 @10:04AM (#26275430)
The vast majority of documents are written in a language anyway so you can safely encode the date in it. Does any other language even have two different, conflicting date formats like that?
Re:ISO 8601: a better date format by TeMPOraL on Friday February 26, 2021 @10:41AM (#26275839)
English is the only one with conflicting date formats I can think of (US vs UK), but in case of government and corporate documents, those are sometimes bilingual - with form labels in the primary language having a small-font translation to English below.

(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.)

Re:ISO 8601: a better date format by joshspankit on Friday February 26, 2021 @09:11AM (#26274891)
No.

People were unfamiliar with showering and brushing their teeth. We move forward.

Re:ISO 8601: a better date format by cesarb on Friday February 26, 2021 @08:36AM (#26274600)
> ISO 8601 everything. [...] on government forms

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).

Re:ISO 8601: a better date format by TeMPOraL on Friday February 26, 2021 @09:56AM (#26275360)
You don't need the Internet for ambiguity to occur, you only need to go international. It may be because you travel, or work with foreigners, or handle mail/packages to/from abroad. Or use any kind of software, because unless you live in the US, almost all software you use is made by foreigners in a foreign country.

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.

Re:ISO 8601: a better date format by andy_ppp on Friday February 26, 2021 @04:07AM (#26272786)
Format the date on the frontend using date.toLocaleDateString() and let the browsers locale do the work for you (assuming you’re in JS and on the web).
Re:ISO 8601: a better date format by TeMPOraL on Friday February 26, 2021 @04:26AM (#26272916)
No. The computer cannot magically detect the preferences of an actual user. This is a kind of "90% solution" that excludes people whose locale setting doesn't match their preferences, which is arguably quite common. Reasons include buying your OS/computer from abroad, or one that was imported and resold, getting a work machine set up for a different country, not knowing how to fix locale up yourself, traveling (localizing websites based on user's location is idiotic, but it keeps happening)....

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.

Re:ISO 8601: a better date format by andy_ppp on Friday February 26, 2021 @05:49AM (#26273462)
Okay, well I'm pretty sure for most apps I've worked on this has been fine according to business requirements and solved the problem of our users. Do you have statistics on which users have their locale's set wrongly and can you explain why the browser provides this functionality? Maybe you should campaign for it to be removed on their mailing lists?

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.

Re:ISO 8601: a better date format by alexvoda on Friday February 26, 2021 @08:05AM (#26274354)
That's why we have international standards. So that 1 version of right and all others are wrong. And no matter how arrogant it might seem, at least for computing use cases, ISO 8601 is right and other date formats are wrong.

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.

Re:ISO 8601: a better date format by andy_ppp on Friday February 26, 2021 @03:27PM (#26279477)
I don’t disagree, in an ideal world great, let’s get everyone to change to ISO8601. I’m a big fan. However until developers become in charge of all the decisions (imagine!) I’ve suggested a reasonable solution that most people can use to format dates in 99% of users locales with too much hassle. There are more interesting bridges to die on.
Re:ISO 8601: a better date format by TeMPOraL on Friday February 26, 2021 @05:58PM (#26280851)
> However until developers become in charge of all the decisions (imagine!)

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.

Re:ISO 8601: a better date format by jiggawatts on Friday February 26, 2021 @05:32AM (#26273358)
Short of stepping through the JavaScript line-by-line, how do you tell the difference between these two dates?

    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.

Re:ISO 8601: a better date format by zeckalpha on Saturday February 27, 2021 @04:01AM (#26283615)
31/11/2021 is quite ambiguous, I can’t find such a date on my calendar, by either notation.

I’ve scheduled cron jobs for February 31st, to have them tracked but disabled.

Re:ISO 8601: a better date format by andy_ppp on Friday February 26, 2021 @05:54AM (#26273490)
You're making the assumption that users know YYYY-MM-DD is the date format and not YYYY-DD-MM. I bet if you asked non-developers the answers you would get would be pretty random, probably more errors than the locale on their machine.
Re:ISO 8601: a better date format by beowulfey on Friday February 26, 2021 @06:48AM (#26273833)
the point is, no program writes the date YYYY-DD-MM (or at least, it's very rare).

users who don't know what ISO 8601 is would learn, simply because when that format is used in software, it is consistent!

Re:ISO 8601: a better date format by skissane on Friday February 26, 2021 @07:54AM (#26274266)
> YYYY-DD-MM (or at least, it's very rare)

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).

[0] https://en.wikipedia.org/wiki/Date_format_by_country

Re:ISO 8601: a better date format by rhn_mk1 on Friday February 26, 2021 @04:20AM (#26272877)
> Date().toLocaleDateString() > Uncaught TypeError: Date().toLocaleDateString is not a function

That doesn't seem like a standard API call.

Re:ISO 8601: a better date format by bmn__ on Friday February 26, 2021 @04:39AM (#26273010)
It is standardised and widely implemented.

https://developer.mozilla.org/docs/Web/JavaScript/Reference/...

Your code has a bug, missing constructor.

Re:ISO 8601: a better date format by teh_klev on Friday February 26, 2021 @08:56AM (#26274758)
Looks like an instance method, rather than a static.