Tangentially related: I hate GNOME's approach at configuring formats. In their format settings, you have to pick a country and that determines the format of dates, time, numbers, and the unit system. Of all the countries, none of them has the sane choice for all of the fields, namely: ISO 8601 for dates and times with 24h (no AM/PM), metric system (or SI, whatever), and dot as decimal separator. You can have sane dat…
ISO 8601: a better date format
191–200 of 437 posts
Re: ISO 8601: a better date format
#192Earlier quoted context omitted.
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…
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).
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
#193Earlier quoted context omitted.
Any choice is arbitrary. What is a week to the solar system? The only things that are real are days and years.
What is a day in the solar system? What is anything anywhere anyway? That’s not the point. The point is that in the US people typically work Mon-Fri and loaf around Sat-Sun (weekend) and yet the week starts in Sundays. It’s infuriating.
Re: ISO 8601: a better date format
#194Earlier quoted context omitted.
M/D/Y is a bit like the German way of reading numbers. 328 become three hundred, eight and twenty. Terrible
How about french? 99 is four twenties nineteen, 79 is sixty nineteen. Languages are fun and fascinating.
Re: ISO 8601: a better date format
#195Earlier quoted context omitted.
Probably those are from the locales package? en-dk is the best one, it is Europe standard english which I think fits all your requirements for Saneland.
en-se is slightly closer, as it has an ISO 8601 date, but like en-dk it still has a comma decimal separator, and the clock has a dot separator (13.49). An artificial en-xi or similar is probably best: take en-ie, and just change the short date format.
https://github.com/lattera/glibc/blob/master/localedata/loca...
Re: ISO 8601: a better date format
#196Earlier quoted context omitted.
I have taken to writing 11 March 2021 or similar whenever possible. But sure, 2021-03-11 is also fine, when trying to save something machine readable. The US conventions are indeed horrendous.
Another great thing about 2021-03-11 is that, even putting aside its technical advantages, it is (probably) intuitively understandable to any literate person even if they have never seen it before and, most importantly, it is almost immune from confusion because (hopefully) nobody is insane enough to expect YYYY-DD-MM. YYYY-MM-DD both satisfies the American intuitive expectation of month coming before day, and the Wo…
Re: ISO 8601: a better date format
#197Free versions of the actual specs: https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i... https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_i... Or https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en The ISO8601 yyyy-mm-dd format is fine and intuitive. What trips people up all the time is the ISO8601 yyyy-www-d format (year-week-weekday)[1]. People who know it well can appreciate the benefits…
So many people are unaware that the ISO8601 format allows "week date" and/or don't understand its quirks, and articles like this one, which don't even mention that ISO8601 dates can appear in this format, compound the problem.
Re: ISO 8601: a better date format
#198Earlier quoted context omitted.
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).
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 (local…
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
#199There's another aspect you may not know about: It's close to how it's done in chinese, which is 2021年3月17日. They use different separators (the chinese words for year, month and day), but it's close enough. Given that china is the country with the largest population it may not be a bad idea to use something a large number of people will easily understand.
Re: ISO 8601: a better date format
#200Earlier quoted context omitted.
M/D/Y is a bit like the German way of reading numbers. 328 become three hundred, eight and twenty. Terrible
How about french? 99 is four twenties nineteen, 79 is sixty nineteen. Languages are fun and fascinating.
- to an outsider, learning that a concept exists: “that is an interesting thing”
- to a beginner, trying to construct the right form or to detect it in quickly spoken speech: “this is annoying and I hate it”
- to an intermediate speaker and beyond: “eh it’s maybe weird but whatever”
I used to hate noun declension in Czech as a beginner (7 cases x plural/singular = 14 forms a noun can take[0]) because it’s intimidating and unintuitive for an English speaker, but now I’m at the “meh” stage.
[0] - then consider that there are 3 genders, and each gender has a handful of “models” (patterns for declining words that look a certain way), and also a bunch of exceptions. Not the hardest thing in the world, for sure. But it’s definitely a bit of a pain