You don't need libraries for internationalization of dates

Re:You don't need libraries for internationalization of dates by patelpankaj on Wednesday February 19, 2020 @04:46AM (#22364217)

Author of the post here; the gist of above post:

You can use Date.prototype.toLocaleString and its customizable API to get the localized output easily. Like in the following example, we will use the Locale String to easily get the Readable Date desired by the user

[ Parent | on HN ]

Re:You don't need libraries for internationalization of dates by jamestomasino on Thursday February 20, 2020 @07:05AM (#22374448)

Last I checked the formatting results of toLocaleString differ between browsers and NPM for certain locales. A quick search finds a handful of issues on Github about it, but I'm pretty sure there's a more in-depth stack overflow discussion too. I'm not sure if this will all be superseeded by the new date handling proposals or not, but it's something to be wary of.

[ Parent | on HN ]

Re:You don't need libraries for internationalization of dates by taeric on Thursday February 20, 2020 @08:48AM (#22375011)

I would think that https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... would be a better choice. That said, I expect localization to just always be broken.

[ Parent | on HN ]

Re:You don't need libraries for internationalization of dates by GreenJelloShot on Thursday February 20, 2020 @01:29PM (#22377309)

Title of the article: "You don't need Libraries for internationalization (i18n) of Dates"

Actual content: "... you might not need any of these libraries [moment, dayjs, date-fns] to have some basic Formatting and Localization on the Date Objects."

[ Parent | on HN ]