Live data from Hacker News

ISO 8601: a better date format

kirby.kevinson.org

191–200 of 437 posts

Re: ISO 8601: a better date format

#191

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…

XFCE allows you to set a strftime string for date format.

Re: ISO 8601: a better date format

#192

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

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

#193

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

What practical difference does it make to you? The week starts whenever you decide it starts. Would it annoy you even more if I decided to start my week on Thursday?

Re: ISO 8601: a better date format

#194
post #145

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

And since the French say ten nine instead of nineteen, it becomes four twenties ten nine.

Re: ISO 8601: a better date format

#195

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

en-dk has ISO 8601 though you're right it uses the comma.

https://github.com/lattera/glibc/blob/master/localedata/loca...

Re: ISO 8601: a better date format

#196

Earlier 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…

Non-scientifically, about 20% of people won't: https://twitter.com/troyhunt/status/978747364105011202

Re: ISO 8601: a better date format

#197
post #73

Free 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…

The "week date" format (yyyy-www-d) in ISO8601 is IMHO why it's usually better to refer to RFC3339, which doesn't allow the week date format.

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

#198

Earlier 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…

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

#199
post #9

There'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.

Sounds like the convention used in some countries for time, using e.g. 9h20 instead of 9:20

Re: ISO 8601: a better date format

#200
post #145

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

I think your response to these language quirks can vary depending on your familiarity with the language:

- 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

Post reply on HN