3 ms·

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 famil

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

by divan 4y ago

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.