4 ms·

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

rhn_mk1 6y ago
> Date().toLocaleDateString() > Uncaught TypeError: Date().toLocaleDateString is not a function That doesn't seem like a standard API call.
- bmn__ 6y ago
  It is standardised and widely implemented. https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString#specifications https://developer.mozilla.org/docs/Web/JavaScript/Reference/... Your code has a bug, missing constructor.
- teh_klev 6y ago
  Looks like an instance method, rather than a static.
TeMPOraL 6y ago
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.
- andy_ppp 6y ago
  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.
  - alexvoda 6y ago
    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.
    - andy_ppp 6y ago
      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.
      - TeMPOraL 6y ago
        > 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.
jiggawatts 6y ago
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.
- andy_ppp 6y ago
  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.
  - beowulfey 6y ago
    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!
    - skissane 6y ago
      > 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 https://en.wikipedia.org/wiki/Date_format_by_country

rhn_mk1 6y ago

> Date().toLocaleDateString() > Uncaught TypeError: Date().toLocaleDateString is not a function That doesn't seem like a standard API call.

bmn__ 6y ago
It is standardised and widely implemented. https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString#specifications https://developer.mozilla.org/docs/Web/JavaScript/Reference/... Your code has a bug, missing constructor.
teh_klev 6y ago
Looks like an instance method, rather than a static.

TeMPOraL 6y ago

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.

andy_ppp 6y ago
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.
- alexvoda 6y ago
  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.
  - andy_ppp 6y ago
    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.
    - TeMPOraL 6y ago
      > 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.

jiggawatts 6y ago

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.

andy_ppp 6y ago
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.
- beowulfey 6y ago
  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!
  - skissane 6y ago
    > 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 https://en.wikipedia.org/wiki/Date_format_by_country