4 ms·

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

by 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
  - jbboehr 4y ago
    > 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.
    - Smaug123 4y ago
      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.
      - jbboehr 4y ago
        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.
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.

by divan 4y ago

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
- jbboehr 4y ago
  > 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.
  - Smaug123 4y ago
    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.
    - jbboehr 4y ago
      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.

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.