6 ms·

The insane bit about date formatting is recognised to be insane by the Golang team themselves. To quote https://pkg.go.dev/time https://pkg.go.dev/time: > It i

The insane bit about date formatting is recognised to be insane by the Golang team themselves. To quote https://pkg.go.dev/time https://pkg.go.dev/time: > It is a regrettable historic error that the date uses the American convention of putting the numerical month before the day. Such a "historic error" is literally impossible if you use the "MMddyyyy crap": it's always clear from context what format is in use. (I mean, in what world is it even remotely memorable that the canonical order is month, day, hour, minute, second, year, timezone? That decision is just… really bad!)

divan 4y ago
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?
- Smaug123 4y ago
  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".
  - divan 4y ago
    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?
    - OtomotO 4y ago
      It's not common in any software I've written or touched in my entire career.
      - divan 4y ago
        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.
        OtomotO 4y ago
        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.
    - lelanthran 4y ago
      > 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.
      - divan 4y ago
        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 https://www.statmethods.net/input/dates.html
- p-e-w 4y ago
  > 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".
  - divan 4y ago
    Most people can remember "January 2nd" and don't think about US-date vs non-US date.
    - deivid 4y ago
      Or "the second of January", as it may map better to your language ("El dos de Enero")
      - fcarraldo 4y ago
        Or “le deuxième de janvier”, or “der zweite Januar”, or…
    - moogly 4y ago
      Well... January 2nd? or January 2? or 2 January?
      - divan 4y ago
        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.
- XorNot 4y ago
  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).
  - divan 4y ago
    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.
    - masklinn 4y ago
      > 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?
      - foldr 4y ago
        OP was talking about an issue unrelated to time formatting in the part you quote (the lack of a timezoneless time type).
      - divan 4y ago
        Because they're not that smart as HN commenters, obviously. Be compassionate.
divan 4y ago
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.
- masklinn 4y ago
  > 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).
  - divan 4y ago
    > 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".
    - 4y ago

divan 4y ago

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?

Smaug123 4y ago
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".
- divan 4y ago
  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?
  - OtomotO 4y ago
    It's not common in any software I've written or touched in my entire career.
    - divan 4y ago
      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.
      - OtomotO 4y ago
        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.
  - lelanthran 4y ago
    > 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.
    - divan 4y ago
      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 https://www.statmethods.net/input/dates.html
p-e-w 4y ago
> 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".
- divan 4y ago
  Most people can remember "January 2nd" and don't think about US-date vs non-US date.
  - deivid 4y ago
    Or "the second of January", as it may map better to your language ("El dos de Enero")
    - fcarraldo 4y ago
      Or “le deuxième de janvier”, or “der zweite Januar”, or…
  - moogly 4y ago
    Well... January 2nd? or January 2? or 2 January?
    - divan 4y ago
      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.
XorNot 4y ago
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).
- divan 4y ago
  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.
  - masklinn 4y ago
    > 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?
    - foldr 4y ago
      OP was talking about an issue unrelated to time formatting in the part you quote (the lack of a timezoneless time type).
    - divan 4y ago
      Because they're not that smart as HN commenters, obviously. Be compassionate.

divan 4y ago

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.

masklinn 4y ago
> 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).
- divan 4y ago
  > 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".
  - 4y ago