Hacker News Reader

Comment by jiggawatts | Hacker News Reader

The real advantage is that Azure and AWS and every other US-centric cloud service insists on showing me that something happened on the 3/11/2021.

It's a wild guess to figure out if that is the 11th of March or the 3rd of November.

Unless there's also another date with a number higher than 12 in it, there is no way to tell. None. None whatsoever.

For US staff with US regional settings, it's always obvious which date is correct. That is the one single case where there is no confusion. This works as expected for just 4% of the world population, but it is those 4% of the world that get to decide the date format.

It's the most obnoxiously American attitude imaginable to ignore this issue because it doesn't affect them... only the other 96% of the planet.

/rant over

View on HN

> It's the most obnoxiously American attitude imaginable to ignore this issue because it doesn't affect them...

As an American I can fully confirm that 3/11/2011 is obnoxiously ambiguous. It affects us. But most Americans (particularly outside of science / engineering fields) are too thick-headed to recognize the problem or think about ways to improve it.

So I do what I can. I don't even ask what time format something belongs in. I just write ISO8601 by default. If someone complains then I point them to the international standard and ask whether we want to be an internationally standards-compliant company.

One manager said that our customers aren't international. It was a reasoned argument and I like having customers. But all others drop the argument at "international company" and "standards-compliant"

Point them at the fiasco where NASA mixed up Imperia and Metric.

And also ask but why are we not targeting international customers.

I have indeed done the former when discussing why I use meters instead of feet.

The latter was an ice rink whose customers are very physically local. Local teams do compete internationally but the ice rink itself isn't an international org.

>So I do what I can. I don't even ask what time format something belongs in. I just write ISO8601 by default. If someone complains then I point them to the international standard and ask whether we want to be an internationally standards-compliant company.

This is my approach as well. I've never gotten a complaint about it, which proves to me that the format is understandable AND unambiguous.

How can you take an international standard seriously when it is based on the number of years since some prophet of some specific religion was thought to be born?

Can you suggest a better alternative which you would take seriously? A Kelvin-like year based on the approximate date of the Big Bang (as CE/BCE is based on an approximate year)? Logical but unwieldy.

I’m down for the years to be counted from the storming of the Bastille, personally...

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.

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

> Date().toLocaleDateString() > Uncaught TypeError: Date().toLocaleDateString is not a function

That doesn't seem like a standard API call.

It is standardised and widely implemented.

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

Your code has a bug, missing constructor.

Looks like an instance method, rather than a static.

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.

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.

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.

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.

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

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.

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.

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!

> 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

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.

Yes! I constantly get complaints when using ISO 8601 on school documents. But I won't stop using it.

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?

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

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?

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

No.

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

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.

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!

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

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.

It took many decades to widely adopt UTF-8. I think that one of the reasons was that US companies did not really care about character encodings, as it's not something they have to often deal with. Even today managing multiple keyboard layouts is a pain in most operating systems, it's buggy, it does not have enough configuration options, it's not convenient. Probably because most US developers never tried to use that functionality.

Mac Firefox and Mac Chrome both break a bunch of keyboard shortcuts if you use a non-US-ANSI keyboard. Safari handles alternate layouts correctly.

Just yesterday I learned that on an ISO Spanish keyboard, both of those browsers will pop up a help menu for ⌘⇧7. The logic goes: ⇧7 means / on a Spanish ISO keyboard, and ⇧/ means ? on a US-ANSI keyboard, therefore ⌘⇧7 is by the transitive property of inter-layout shift functions equivalent to ⌘?, which is the shortcut for opening the help menu.

They don't pop open the help menu if you press ⌘⇧', the actual ISO Spanish layout way to type ⌘?

Stuff like this is the reason why I, as a non-american software engineer, use `US_en` layouts on all my machines.

I use a Japanese keyboard that pretends to be a US-ANSI on my laptop. The extra keys and narrow spacebar are super handy.

Something like http://www.keyboard-layout-editor.com/#/gists/9150730dbd4d28...

Same. When I have to use someone else's computer without an US_en keyboard I look like an elder learning to type.

I use EurKey [0] (I think this was actually recommended to me on HN) so I have easy "AltGr" access to German characters like öüß. Sadly some tools (most notably Microsoft’s) have hardcoded shortcuts for some of those, which is really annoying.

[0]: https://eurkey.steffen.bruentjen.eu/

I use the Canadian English layout on macOS for most of the time, if I need to enter accented letters, I can just hold down a normal letter (A) then select an accented one from the popup (Å). The international English layout works the same way if I remember correctly.

Not only Firefox. Cmd-/ is also a very common "toggle line comment" shortcut. I think it's the default on Sublime and IntelliJ, and any editor that offers a "Sublime compatible" preset (like VS code) imitate that. Of course, such a shortcut broken out-of-the-box for any keyboard layout that lacks a / key.

Yeah, Sublime copied this shortcut (like most of its features) from TextMate, and it has since spread widely.

Amusingly, TextMate's author and many early users were European programmers with US-ANSI keyboards (because the various European layouts are just too painful for writing code in ASCII-based programming languages).

Mac everything breaks for me on a UK Mac when using an ISO keyboard rather than their non-standard ISO layout.

Page down only sometimes works, and Command+~ to switch same app Windows works in some apps and not others. It's a bit of a train wreck when you want to get rid of their pointless keys.

The built-in apps seem to handle it pretty well (ex. the dictionary app has ⌘Ä / ⌘Ö shortcuts when set to Swedish). 3rd party apps often don't care and it gets worse the more you move away from plain QWERTY.

Although macOS is good in the aspect that combinations akin to AltGr on PCs aren't unique to non-US layouts. I've seen programmers assume it's safe to assign shortcuts to Ctrl-Alt (which simulates AltGr), making it impossible to enter certain characters. Not surprising, as it's not used on the US layout (just as there's no extra key next to the left Shift).

And multiple languages. Spell-chackers enabled by default are specially annoying.

But contrary to the date issue, you could at least make a case for using ASCII everywhere. I'm not saying it has no downsides (e.g information density). It may also be unrealistic and culturally insensitive, but there are very clear upsides as well. Not so with the U.S date format. It's just bad.

Until people get used to emoji... And not supporting UTF-8 is suddenly a big problem even for English people now.

My wife recently bought by mistake a keyboard whose layout I couldn't figure out. It took me a full 5 minutes to even get to the correct place where I could configure keyboard layouts under Windows 10 settings. Then I had to choose the keyboard layout I wanted to add. This was a list in a dropdown with hundreds of options without an image of what each layout looks like so I could not check which option matched the keyboard in front of me. There was not even an input field where I could test the chosen layout, I had to switch back and forth from the Notepad. After many tries, I finally got it right: Portuguese. Completely by trial and error.

I like the method that Mac OS uses to detect the layout of a newly connected keyboard. It brings up a dialog asking the user to press specific keys (something like "type the | character") until there is only one possible layout that would generate the observed keycodes for the characters in question.

It’s really well done - and usually Identifies the most common keyboards in only a few key presses.

Same method as certain mainstream Linux distros has been using the last few years? Or has Mac been doing this for even longer (I cannot remember how it worked back in 2012, the last time I used Mac.)

Another example of obnoxious American attitude: the TZ variable in POSIX.

TZ=UTC+8. Is your system now set to the timezone UTC+8? No, it's set to UTC-8. Why? I don't know, but I suspect the people who developed this convention, who lived in the US, just didn't want to type a minus.

The TZ format counts how many hours behind UTC you are (how many hours should you add to get UTC time). The ISO format counts how many hours ahead of UTC you are. Neither choice is inherently correct, but the discrepancy is pretty annoying.

Use https://en.wikipedia.org/wiki/Tz_database names instead.

It is exaclty this attitude what makes the datetime format in Golang extremely difficult to use. I always have to double check my formatting. I like the basic idea very much, but its logic only works for 'local' Americans.

    The reference time used in the layouts is the specific time:
    Mon Jan 2 15:04:05 MST 2006
    which is Unix time 1136239445. Since MST is GMT-0700, the reference time can be thought of as
    01/02 03:04:05PM '06 -0700`

Golang was not meant to become a big international language from the start? Just a fun internal Google project ;-)

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 Worldwide expectation of time units being displayed in a logical order.

I have seen non-Americans write YYYY/DD/MM before. Hyphens are key here.

That is horrifying.

I am glad I have never met these people.

yyyy.dd.mm. (but not with hyphens!) are commonly used for all the languages where their grammar and word order means that the spoken way to say dates is like "twothousandtwentieth year's first march".

eye_twitch.gif

Another great thing about 2021-03-11 is that it ascii sorts correctly.

This is the big one when it comes to sorting files and directories on disk. It makes sorting and finding what you look for so much easier.

> 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,

I disagree. (Or, perhaps I’m insane...) I paused when coming across the ANSI version in the article as I couldn’t tell whether it was YYYY-MM-DD or YYYY-DD-MM. I thought there was a typo or something.

I’ve nothing against the standard, but as Americans have no ‘intuitive’ reason to sort the fields by significance, it is natural for some to incorrectly assume the ANSI version is just the American version written backwards.

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

I don't think it's fair to assume that the people choosing the WTF option would not have interpreted the format correctly if they had to pick an actual interpretation.

I also always write 11 मार्च 2021 or similar whenever possible. No problems so far.

I go with 「２０２１年０３月１１日」. Free bonus test included for whether software handles alternate numerals ;)

Tangent, but I do like the space-efficiency in some cases for Chinese/Japanese characters that make them great for status bars and terminal prompts.

E.g. a single character to unambiguously denote weekday, window layout (全／広／高）, and others. Renders everywhere as long as you have a decent CJK font. Bonus: looks a lot less stupid than emojis.

My desktop terminal prompt right now shows [金 19:58:22] - just a single character and as long as it's < 7d ago it's unambiguous what time and day a command exited in case I forget.

Absolutely agree. Also in some cases you get "tables" aligned for free (... if there's nothing else length-varying.)

> My desktop terminal prompt right now shows [金 19:58:22] - just a single character and as long as it's < 7d ago it's unambiguous what time and day a command exited in case I forget.

You're a bit cheating there :) It's one character that takes up 2 columns.

You could get away with using the first 2 characters from the English names as they are unique. But I know that in English that's unusual but for example in German, the 2 letter abbreviation are the standard ones.

You say weekday, but Google translate and Wikipedia say that 金 means gold?

Maybe a bit cheating - but it's nice with the consistency, and visually it becomes a lot more clear and immediate at least for me.

"金" would be short for "金曜日", a common way to abbreviate weekday names in calendars etc and yes, Friday is indeed the day of gold - I like to imagine it's the old pay day for workers maybe? :D

金 from 金曜日 (Kinyōbi) means Friday. The letter correspond to the planet the weekday was named after, just like in English (金星 is Venus)

The planet-weekday combination is harder to see in English than e.g. in Romance languages like French because English derived its planet names from Roman gods, but its weekday names from Norse gods (e.g. Friday comes from Freya). German is similar, having Freitag for Friday (again from Freya) and Donnerstag for Thursday (from Thor).

Slightly off, but this is fun, so let me expand (along with a minor correction):

The days of the week were named after the seven classical planets of astrology (by the Romans, who in turn named the seven classical planets, and hence the days, after Roman deities).

The names were taken up by speakers of Germanic languages, and eventually underwent semantic loan translation: Germanic deities were substituted for the Roman ones (with the exception of Saturday). Some people say that the Germanic deities themselves were culturally identified as one and the same as the Roman deities, but we probably won't ever know for sure (interpretatio germanica, analogously to the interpretatio graeca, the identification of Egyptian, Roman and Greek deities [1]).

And now, a minor correction: The day of Venus, Friday bears the name of the Germanic goddess Frigg, who is not the same as the Norse goddess Freyja. The meeting of the two characters, in a debate against Loki, is described in the Poetic Edda [2].

[1] https://en.wikipedia.org/wiki/Interpretatio_germanica [2] https://en.wikipedia.org/wiki/Lokasenna

Sure you can tell. You just hire an investigator to find out who wrote the memo, and find where in the world they grew up, in what culture.

If the answer comes back very US, then it's middle endian US format. Else it's DMY.

Note that the article is wrong to just say "dd.mm.yy" is used in "Europe". Some countries use yyyy-mm-dd and others dd/mm/yy.

The US format is the only one that's retarded, though.

> The US format is the only one that's retarded, though.

I wonder how it started? A skim of the internets hasn’t enlightened me.

It’s a representation of how us Americans talk - we rarely say 26th of February and instead say February 26 - and if necessary tack on the year. It feels exceptionally awkward to say 26 February, thought saying “twenty twenty one February 26” sounds very strange, too.

But people are very good at verbally saying different than is written.

So write YYYY-MM-DD!

But also, the most sacret of all days has been honored by the one day of the year "said properly" fourth of july!

Changing formats is just asking for a large event on 9 November.

No native speaker but isn't 4th of July more common than July 4th?

You could even say "The Fourth" and almost all Americans would understand. I think that's why; [begin speculation] it's such an exceptional date it necessitates saying it differently.

The Fourth of July and Cinco de Mayo are exceptional days.

Tax day is the ides of April, but we just say April 15th.

Somehow the rest of the anglosphere doesn't use that format.

Canada is even worse, we can't decide which one to use so you never know what format it's in.

I was once sent paperwork to fill out that had dates requested in both MM/DD/YYYY and DD/MM/YYYY formats on different pages.

the upside of Canada's incredibly stupid date formats is that nobody complains when you try to use ISO8601 format instead, we're all somewhat used to date formatting being flexible.

My american users get very angry when they see a date that isn't in dd/mm/yy format.

Corrections: Most but not all government forms in Canada use yyyy-mm-dd format, which is a positive change. But indeed we are used to living in a mishmash of American, European, and ISO influences. Americans might get angry if you don't use mm/dd/yy format; I'm not aware of them being attached to dd/mm/yy.

It doesn't help at all if they try to localize it because then it's just 11/3/2021 which is equally confusing and you have no idea if they're using your local format or theirs. Any what's your local format? The country you're in or the country you were in when you signed up for the service or the country your VPN server is in? Internet services really need to stop using these stupid mistake-inducing, time wasting date formats. People might have a sense of unfamiliarity seeing ISO8601 format but they can still understand it.

I use ISO8601 dates everywhere possible. Paper forms in the real world where people look at me strangely, invoices, file names which is really handy for sorting, my personal todo lists, everything.

This reminds me about Americentrism: https://jlelse.blog/thoughts/2021/02/americentrism

America first!

I don't know, I'm German and deal with US folks a lot, for me it's like this: Date written with slashes or dashes (3/11/2021 or 3-11-2021) implies US-based month/day/year. Date written with dashes and the year first and zero-padding (2021-03-11) implies year-month-day, aka ISO8601. Date written with dots and without padding (11.3.2021) implies my native format, day.month.year.

Isn't the point of ISO to eliminate that guess/search process and replace with 100% accuracy on read?

Yes, if everyone follows ISO.

And that starts with you.

I live in Sweden, so I actually do use ISO...

but then you get an email from an American living in Paris and it's 11/3/2021 with dashes and God knows what he meant.

UK/Ireland are pretty interchangeable about the seperators, but I'd guess D/M/Y has a strong lead over second place d/m/y, while d.m.y is trailing in last.

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.

But nineteen is just "nine and ten" with the "and" removed.

English has a word for twenty and its used in the French way "Four score and seven years" is "quatre-vingts et sept".

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

I’ve always thought it’s interesting how the languages like that (most of the Romance languages have declensions and such) add error detection and even correction - you can figure out parts that are missing or got changed by the lack of agreement between the various forms.

You may not be able to correct it from the Information available but you’ll know something went wrong.

Still better then russians: ten, twenty, thirty, bag of furs, fifty, sixty, ...

This explains, to me, at least, the whole "four score and seven years ago" speech. I always wondered the reason behind such a silly way of presenting a number, I just figured it was archaic.

Nope, just French.

Let's not even talk about Danish numbers.

Oh interesting, from wiki

   56 - seksoghalvtreds(indstyve) - six and [two score plus] half [of the] third (score)

Same deal in Slovenian. Twenty one is written as "enaindvajset" ("ena" - one, "in" - and, "dvajset" - twenty) which is the same format as used in German ("einundzwanzig").

The AWS console is absolutely terrible for this, not just because it disobeys my preferred date format but because it's not even internally consistent. sometimes it converts timestamps to my local timezone, sometimes it displays them in UTC, sometimes it displays them in ISO8601 format, sometimes it displays them in US format.

The best part is when someone tried to make it work for the other 96% of the world but failed for 2% of the dates (probably because the other locales got less testing, again very US centric), so one ends up with mixed US/EU dates (the latter often also uses / as a separator, as . is only used in some EU countries).

It's so much fun trying to retrospectively correlate fatal incident data and failing to make sense of anything because some dates are inconsistent. Of course those dates are all the ambiguous kind, otherwise it wouldn't be -that- hilarious /s.

On presentations for projects I tend to add a couple of 'fun' slides. When said projects involve people in the USA, I (almost always) include the XKCD ISO 8601 cartoon:

https://xkcd.com/1179/

It is one of my favourites (the "8601", the "Security", and the "Bobby Tables")

You can change the display format, but I really wish M/D/Y wasn't the default - it's just too ambiguous.

This is mentioned in the article....

> only the other 96% of the planet

Ahem, ISO8601 fails for Taiwan and Japan...

How does it "fail"? Taiwan has different year numbers but they are sufficiently offset to avoid disambiguity and IME people can read normal years just fine. Anyway, the year-month-day order seems to be the same.

It's more obnoxious to be lectured by people who think "June 3rd, 2021" isn't shorthand for "AD 2021 June 3rd", which is proper logical and sorting order.

You're saying that 06-03-2021 is shorthand for 2021-06-03 and are confused why people don't get that?

If it is in the browser it is probably just displaying using you local date time format

Ha, no.

> It's the most obnoxiously American attitude imaginable to ignore this issue because it doesn't affect them... only the other 96% of the planet.

I’m not going to comment on the author, though I will acknowledge the abrasive, unhealthy attitude.

Anyway, no. I don’t think there’s a clear “American” standard. Maybe there once was, but I’d just see a pile of numbers these days. It’s hostile to the consumer as it inherently leaves some uncertainty of how it should be consumed.

I will say, and maybe this is American - but I don’t think it is - that I often see dates formatted unambiguously as, e.g. March 11, 2021.

It is American. In the UK, we'd write 11th March 2021. But I don't mind too much when it's non-ambiguous like this.

Is that also how you’d say it? If verbally asked what tomorrow is would you say “twenty seven February” or “twenty seventh February” or “twenty seventh of February”? Americans normally would say “February twenty seventh”.

Yes. The 27th, or the 27th of February.

To us, US English seems to skip a lot of the small joining words of various flavours.

Well you're actually saying "the 27th day of the month of February" and removing some of the small joining words of various flavors. :) /s

On the Twenty Sixth day of the Month of February in the Year of Our Lord Twenty Hundreds and Twenty and One, lo did rswail post.

Reply on news.ycombinator.com