This clause is just about slight inconvenience for non-US citizens to remember the order of month and day, and not about not using letter-mapping approach, which in some languages is using the whole alphabet.

Are you intentionaly trying to misrepresent that clause of "regrettable error" or didn't read carefully?

> slight inconvenience for non-US citizens

So, 96% of the world's population?

And even in the US, science and engineering projects commonly use ISO dates.

Go's date formatting is as if a random American had taken a quick glance at a paper calendar pinned to the side of their fridge, and decided "yeah, let's do it like that".

Most people can remember "January 2nd" and don't think about US-date vs non-US date.

Or "the second of January", as it may map better to your language ("El dos de Enero")

Or “le deuxième de janvier”, or “der zweite Januar”, or…

Well...

January 2nd?

or

January 2?

or

2 January?

Just remember the date and use it in your date formatting string.

If you want today to be printed as "December 11" put "January 2" in your Format() call. If you want "11 December", put "2 January". No need to remember any alphabet mappings anymore, it's way simpler.

Do you have a source for that statement? (For all I know, you are a member of the team who wrote it, so you may know what it means! I certainly had nothing to do with its writing.)

To me, the statement is obviously saying "yeah this order is just bizarre, why on earth did we put the two most significant digits around the outside of the rest, good luck".

I'm not a member of a Go team.

I can comment though as a non-US citizen. This "bizzare" US order (month-day-year) is SO COMMON in software that it's very familiar. Like most of the software historically was born in US, and it's just a very common case where localization is not respected and you see american style dates every now and then. It's getting better, but still, not unusual.

While it's different from european, it's definitely not "insane" and not "bizzare". Why would anyone even claim that?

> This "bizzare" US order (month-day-year) is SO COMMON in software that it's very familiar.

I've been using computers since 1986, and I've used many many software packages.

Which software package uses month-day-year outside of the US? Every package uses the locale, so the 94% of the population outside of the US literally never sees this format.

Here, quick example from today. Working with an R-script and needed to check date functions [1] and you got mm/dd/yyyy literally in the docs. Good luck figuring out what "%a" or "%D" means, btw.

Another recent example - I had to fight for two hours with yet another javascript date/time picker to present date in localizaiton of a browser. Turns out this popular picker didn't have proper support for localization and set US one by default.

The same issue I had with Flutter time picker, btw. Not sure if it's been fixed by now, but making proper localization support can be quite challenging even in 2022.

Sure, localization support is getting better each decade, but it's far from perfect. And if you've used software since 1986, then you should remember that at that time the concept of localization DIDN'T EVEN EXIST and majority of the software (including DOS!) used US format (there were "localized" versions of DOS, ofc, but those were even branded differently and the best you could get is codepage, keyboard and printer support).

[1] https://www.statmethods.net/input/dates.html

It's not common in any software I've written or touched in my entire career.

Well, maybe subset of software you written or touched is much smaller than the whole set of software billions of other people wrote or touched.

Oh, without a doubt.

What I mean though: the US isn't the world, even though many people think it is.

And the US date format is among the weirdest I ever encountered.

Super happy I never had to support it. It was enough to support over a dozen different formats at one customer at one point.

> it's definitely not "insane" and not "bizzare". Why would anyone even claim that?

Pretty sure it's just anti-American signalling/globalist cultural imperialism. Asian/8601 date format makes a lot more "logical" sense, but nothing beats what you grew up using, at least for me, in a non-technical context.

Obviously your software should present dates in a locale-aware manner, just as it should (where possible) present localised text. But if it's anti-American signalling to expect reference documentation and technical features for non-localised systems (such as the Go programming language) to use the internationally accepted standards for the presentation of non-localised data, then… sure, I guess I'm happy to signal anti-American?

But I am one of Those People who goes around $WORK's internal wiki (which has users in the USA and GB) telling people off for failing to use 8601 in their meeting minutes, so perhaps take with a pinch of salt.

To be clear, I meant it as a general phenomenon and wasn't directed at you. I see a lot of the same thing on reddit, etc. Metric vs imperial is an almost-daily comment chain in the Oxygen Not Included subreddit, for example. It just gets a bit tiring to see the same discussion again and again.

(edit) I'm perfectly fine using 8601 in technical contexts, or anywhere really, but describing American cultural practices as "insane" and "bizarre" is exactly what I'm talking about.

Then ditch letter mapping and use named parameters: "{day} {month} {year}" etc. The Golang approach already requires complicated string parsing, so a formatting language isn't going to be more complicated, but then the documentation can just tell you exactly what you need to write to get the desired output, rather then debugging whether you got an invisible implied order wrong (with a failure mode of either giving random output, or just literals).

But why? It's so handy in practice!

I work a lot with times (not just dates) and having strings like "15:04" make it immediately recognizible, consise and just right.

What I actually lack in Go's time is ability to work with time only without timezone (like, event starts at "12:00", regardless of timezone). But here is the thing - Go is a programming language, and not "framework with solutions for every use case" as many others. So I just spent 10 minutes and wrote my own type for that and use it happily along with time.Time.

> But here is the thing - Go is a programming language, and not "framework with solutions for every use case" as many others.

So... why did they provide a terrible time formatting routine in the first place if it's not a solution to use cases?

OP was talking about an issue unrelated to time formatting in the part you quote (the lack of a timezoneless time type).

Because they're not that smart as HN commenters, obviously. Be compassionate.

With both approaches you have to remember some sort of mapping technique for date formatting.

What I claim that Go's approach is far superior and easier to remember and use.

Leaving aside "oh, but we used to letters" thing, one of the problems with letters is that it's just o much stuff to remember and it only grows as you use more than one languages on a daily basis. I sometimes switch between 4 languages during the day, and this alphabet juggling goes out of hand very quickly. Like it's unusable without constantly opening documentation pages for strfime-like functions.

I mean, I get the attachment part, but I believe that more efficient approaches should get recognition, not punishement.

> What I claim that Go's approach is far superior and easier to remember and use. [...] I mean, I get the attachment part, but I believe that more efficient approaches should get recognition, not punishement.

The Go approach is barely "more efficient" if your only consideration is exclusively US-centric, it's outright hell everywhere else, because US date formats make even less sense than their units. Go's datetime format is gimmicky, gimpy (it's missing a good fifth of the TR35 fields, to say nothing of the field formats), inextensible, and localisation-hostiles.

It's also telling that while Go made up this nonsense with date formats, they retained the significantly worse and more error prone printf formats for, well, printf, in case mixing the two might have been an option (as it is in python for instance).

> is exclusively US-centric

It's literally not a problem at all. It's just one bit of information to remember in your head (I explained in a sibling comment how common US-style date in software, so for anyone who used computer longer than their last iPhone, it's just one bit of information - either date in US style or not). But with Go formatting it's even simpler - you literally never think about it.

You just remember that it's "January 2nd" and that's it. I'm so surprised that people trying to present it as a huge problem, let alone "insane" or "bizzare".

> It's literally not a problem at all. It's just one bit of information to remember in your head

Your assertions do not make that a reality.

> But with Go formatting it's even simpler - you literally never think about it.

True, because you quickly learn to use something else.

> Your assertions do not make that a reality

What reality? I write Go almost daily for 9 years and was running Golang meetups in two countries for years. I think I have pretty good grasp of what actual problem real people have with dates in Go. Order of day-month in mnemonic ("Jan 2nd" vs "Feb 1st") is literally not a problem. This problem exists only in HN comments of people used to other approaches.

That’s cool. I constantly get tripped up with day/month ordering. Maybe I am dumb, but it is a silly design to defend in my opinion.

Can you elaborate in details how exactly you tripped by this?

Like, when you need to present current date so it looks like "11 December, 2022" - where your issue starts with Go's approach? Can you walk me through your thought process here? I'm genuinly curious.

> Order of day-month in mnemonic ("Jan 2nd" vs "Feb 1st") is literally not a problem

I mean, you literally got it wrong in this comment, so maybe it’s worth considering whether such a simple mistake might be hard to catch and thus cause real production issues?

(The GP was using the US convention to refer to the two dates 01/02 and 02/01, not trying to use two conventions to refer to a different date each.)

Ah, I see. Apologies to GP, but I believe the point is still reinforced - the biggest enemy of an engineer when it comes to dates is ambiguity.

I mean, how often do you have to parse that part of the code? If it is everywhere, you should start writing helper functions or some other abstraction.

In my opinion this is typically a very static part of code bases, it is written correctly once (where you can look at the documentation all day long) and possibly never ever looked back on.