7 ms·

You don't need libraries for internationalization of dates

60 points by patelpankaj 7y ago

patelpankaj 7y ago
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
- jamestomasino 7y ago
  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.
- taeric 7y ago
  I would think that https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat 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.
- GreenJelloShot 7y ago
  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."
fake-name 7y ago
(In javascript, because you can standard library). So yes, you do.
- virtue3 7y ago
  also, for the love of God, if you do any sort of date manipulation, just suck it up and use moment.
  - Aeolun 7y ago
    Moment is huge though.
    - jamwaffles 7y ago
      I've used date-fns (https://date-fns.org/ https://date-fns.org/) with good success. The import structure allows for pretty good tree shaking. It's really good if you only want to format a date in like 2 places in a huge app - don't need to pull in the entire library for that.
  - villek 7y ago
    I recently replaced moment (which is huge like others mentioned) with luxon (https://moment.github.io/luxon/ https://moment.github.io/luxon/). It has pretty much all the same functionality but a way smaller size.
  - enlyth 7y ago
    Moment is huge, its performance sucks and the mutability makes developers shoot themselves in the foot constantly. Trust me there are much better alternatives.
  - untog 7y ago
    For the love of God if you’re in the browser don’t use moment. It’s bulky and slow. Use date-fns and selectively import the functionality you’re actually using.
    - yen223 7y ago
      Note that date-fns right now doesn't have great support for duration calculations: https://github.com/date-fns/date-fns/issues/284 https://github.com/date-fns/date-fns/issues/284 I wound up switching to Luxon because of this. Which is too bad, because date-fns is a fine library otherwise.
galoisgirl 7y ago
You don't need date libraries at all: https://github.com/you-dont-need/You-Dont-Need-Momentjs https://github.com/you-dont-need/You-Dont-Need-Momentjs
- enobrev 7y ago
  If anything, the examples here show why a date library may be worthwhile. There are definitely some examples with the native Date class does a great job, but some of those native examples are awful.
- tlarkworthy 7y ago
  Seems out of date, gziped moment.min.js is only 16.7kb (https://momentjs.com/ https://momentjs.com/), which invalidates the main thrust of the argument (i.e. moment is too big).
  - Cthulhu_ 7y ago
    That's the basic version without locales though, which is what the original subject is about; you need the locales to format a date in a certain locale. With locales it's 67.8K gzipped, over 500KB uncompressed - that's half a MB of Javascript you're asking your browsers to interpret as well.
    - wokkel 7y ago
      And the really funny thing is that the browser you are running this on includes ICU4C which does everything and does it better and is only about 20Mb in size.
      - GlitchMr 7y ago
        You don't need to send ICU4C to the user however, you can depend on it already being installed.
  - untog 7y ago
    16.7kb is still too large if you’re not using it enough to justify the extra download. And given that size doesn’t contain locales, in this context it isn’t going to serve any useful purpose at all.
dr_faustus 7y ago
He's right, what you need is a microservice!
- imron 7y ago
  Preferably installed on a kubernetes cluster so that it can automatically scale.
  - randomdude402 7y ago
    Definitely on AWS, because if it's not on AWS, is it really even in the cloud?
pantulis 7y ago
Knowing how to manage datetime, timezone and DST info is one of the most easy traits that helps identify solid engineers. I've seen my share of half-baked attempts to rewrite stuff that is already available and of course they fail in subtle ways.
blablabla123 7y ago
I think JS still has no proper timezone management like in Go that follows the observation that timezones are almost always tied to an area. Until this is not part of JS, I'll keep using momentjs (or moment-timezone in this case)...
olalonde 7y ago
On a related note, JavaScript is getting a better date library: https://github.com/tc39/proposal-temporal https://github.com/tc39/proposal-temporal.
janpot 7y ago
Also see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
oftenwrong 7y ago
Displaying a date on a web page is so common that there should be an HTML tag for displaying a date in localised format.
- lloydatkinson 7y ago
  https://github.com/github/time-elements https://github.com/github/time-elements
  - oftenwrong 7y ago
    I strongly approve!
  - sli 7y ago
    My first thought reading the parent comment was indeed that WebComponents would be perfect for this. Thanks for the link.
- onion2k 7y ago
  Using <input type="date" value="2020-02-20" disabled=true /> should display in the correct format for the user's OS (there isn't a browser level setting to override it). It feels horrible using an input for display though.
  - levosmetalo 7y ago
    Even that is not that simple. You have set your browser to US-English and you expect your date to be displayed that way in the application, but you see something completely different because your OS happens to be set to French.
    - Xelbair 7y ago
      solution is simple. Lets get rid of all date-time formats except the iso(YYY-MM-DD) one...
      - 7y ago
joekrill 7y ago
There are some use cases where this really won't work. For example, if you're doing something like server-side rendering with React, and then try to "rehydrate" on the client-side, the server-side node version may format slightly differently and cause sudden updates to your UI. Also, I don't believe you can rely on a browser having a particular locale available. I'm not sure how reliable time zone data will be either, if you need to show something in a different time zone. I think for some general use-cases this will work well. But there's still a lot of weird issues around this stuff in the browser.
raxxorrax 7y ago
I am one of those guilty people that still use jQuery since I am used to its syntax compared to web-api. I also think it has a better syntax. While it is true that I can format dates, I would be unsure about compatibility. Moment is nice to use and has a good date arithmetic. That would all be possible without third party libraries, but often you want to subtract 2 weeks from a date and that is just a pain in the arse with timestamps. You also might want to import/export dates to databases, which can be picky about the format. I am no web developer, so others might have better opinions. And I think the author is correct that people not used to certain libraries should try the standard ones first.
- beatgammit 7y ago
  You can always check https://caniuse.com https://caniuse.com for browser compatibility, or the MDN article for whatever feature you're interested in.
wruza 7y ago
A small reminder: internationalization is only one of many operations on dates, and libraries exist because browser api sucks at most of these.
dmitryminkovsky 7y ago
I wonder if this requires you to have locales locally installed? How compatible is this? Recently learned that you can internationalize dates right in your Postgres queries/functions! tps://stackoverflow.com/a/59632278/741970. Postgres has great date functionality in general, but with Linux locales installed you can use it for just about anything date related.
qwerty456127 7y ago
The whole date internationalization thing should be deprecated. Everybody smart enough to use a computer is smart enough to understand ISO 8601 (which is by all means better than any other human-readable way to record a date). I also hate the fact some countries use comma instead of the decimal point (which causes problems often). Keeping these differences alive doesn't seem to serve any good purpose. These things should really be made a part of the metric system.
- jeroenhd 7y ago
  You're either greatly overestimating the literacy of many computer users or you're choosing to apply some kind of "intelligence filter" to your code if you're serious about this. People like reading nice dates and nice words. They're easy to parse for human brains. Sure, "1e6" is nice and short but typing out "a million" is much easier to understand. Giving someone a notification that they have an appointment "next Thursday (2020-02-27)" is a lot clearer than just stating the date. It saves people from having to look up the current date and doing mental math to find out how much time is in between those dates. Nit everyone is a programmer and not everyone likes short and concise data notation. Date localisation exists for a reason and it's not because people like to make developers' lives impossible. Use ISO8601 because of its technical superiority if you want, but don't think it's the final answer to the date/time problem.
  - qwerty456127 7y ago
    > People like reading nice dates How is 2020-02-27not nice? > Sure, "1e6" is nice and short but typing out "a million" is much easier to understand IMHO 1 000 000 is the easiest (sure the 1e6 from is better for bigger numbers). As for "a million" I don't understand anything bigger described this way (billions, trillions etc) - tell me 1 trillion and 2 billions and I have absolutely no idea how much is that. It wouldn't be a problem for me to memorize unless there were not the long and the short system as I rarely have a clue which one is being used. > "next Thursday (2020-02-27)" is a lot clearer than just stating the date Sure, but something like 02.27,2020 is no way better than 2020-02-27, it's just a matter of habit particularly easy to change.

60 points by patelpankaj 7y ago

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

jamestomasino 7y ago
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.
taeric 7y ago
I would think that https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat 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.
GreenJelloShot 7y ago
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."

fake-name 7y ago

(In javascript, because you can standard library). So yes, you do.

virtue3 7y ago
also, for the love of God, if you do any sort of date manipulation, just suck it up and use moment.
- Aeolun 7y ago
  Moment is huge though.
  - jamwaffles 7y ago
    I've used date-fns (https://date-fns.org/ https://date-fns.org/) with good success. The import structure allows for pretty good tree shaking. It's really good if you only want to format a date in like 2 places in a huge app - don't need to pull in the entire library for that.
- villek 7y ago
  I recently replaced moment (which is huge like others mentioned) with luxon (https://moment.github.io/luxon/ https://moment.github.io/luxon/). It has pretty much all the same functionality but a way smaller size.
- enlyth 7y ago
  Moment is huge, its performance sucks and the mutability makes developers shoot themselves in the foot constantly. Trust me there are much better alternatives.
- untog 7y ago
  For the love of God if you’re in the browser don’t use moment. It’s bulky and slow. Use date-fns and selectively import the functionality you’re actually using.
  - yen223 7y ago
    Note that date-fns right now doesn't have great support for duration calculations: https://github.com/date-fns/date-fns/issues/284 https://github.com/date-fns/date-fns/issues/284 I wound up switching to Luxon because of this. Which is too bad, because date-fns is a fine library otherwise.

galoisgirl 7y ago

You don't need date libraries at all: https://github.com/you-dont-need/You-Dont-Need-Momentjs https://github.com/you-dont-need/You-Dont-Need-Momentjs

enobrev 7y ago
If anything, the examples here show why a date library may be worthwhile. There are definitely some examples with the native Date class does a great job, but some of those native examples are awful.
tlarkworthy 7y ago
Seems out of date, gziped moment.min.js is only 16.7kb (https://momentjs.com/ https://momentjs.com/), which invalidates the main thrust of the argument (i.e. moment is too big).
- Cthulhu_ 7y ago
  That's the basic version without locales though, which is what the original subject is about; you need the locales to format a date in a certain locale. With locales it's 67.8K gzipped, over 500KB uncompressed - that's half a MB of Javascript you're asking your browsers to interpret as well.
  - wokkel 7y ago
    And the really funny thing is that the browser you are running this on includes ICU4C which does everything and does it better and is only about 20Mb in size.
    - GlitchMr 7y ago
      You don't need to send ICU4C to the user however, you can depend on it already being installed.
- untog 7y ago
  16.7kb is still too large if you’re not using it enough to justify the extra download. And given that size doesn’t contain locales, in this context it isn’t going to serve any useful purpose at all.

dr_faustus 7y ago

He's right, what you need is a microservice!

imron 7y ago
Preferably installed on a kubernetes cluster so that it can automatically scale.
- randomdude402 7y ago
  Definitely on AWS, because if it's not on AWS, is it really even in the cloud?

pantulis 7y ago

Knowing how to manage datetime, timezone and DST info is one of the most easy traits that helps identify solid engineers. I've seen my share of half-baked attempts to rewrite stuff that is already available and of course they fail in subtle ways.

blablabla123 7y ago

I think JS still has no proper timezone management like in Go that follows the observation that timezones are almost always tied to an area. Until this is not part of JS, I'll keep using momentjs (or moment-timezone in this case)...

olalonde 7y ago

On a related note, JavaScript is getting a better date library: https://github.com/tc39/proposal-temporal https://github.com/tc39/proposal-temporal.

janpot 7y ago

Also see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

oftenwrong 7y ago

Displaying a date on a web page is so common that there should be an HTML tag for displaying a date in localised format.

lloydatkinson 7y ago
https://github.com/github/time-elements https://github.com/github/time-elements
- oftenwrong 7y ago
  I strongly approve!
- sli 7y ago
  My first thought reading the parent comment was indeed that WebComponents would be perfect for this. Thanks for the link.
onion2k 7y ago
Using <input type="date" value="2020-02-20" disabled=true /> should display in the correct format for the user's OS (there isn't a browser level setting to override it). It feels horrible using an input for display though.
- levosmetalo 7y ago
  Even that is not that simple. You have set your browser to US-English and you expect your date to be displayed that way in the application, but you see something completely different because your OS happens to be set to French.
  - Xelbair 7y ago
    solution is simple. Lets get rid of all date-time formats except the iso(YYY-MM-DD) one...
    - 7y ago

joekrill 7y ago

There are some use cases where this really won't work. For example, if you're doing something like server-side rendering with React, and then try to "rehydrate" on the client-side, the server-side node version may format slightly differently and cause sudden updates to your UI. Also, I don't believe you can rely on a browser having a particular locale available. I'm not sure how reliable time zone data will be either, if you need to show something in a different time zone. I think for some general use-cases this will work well. But there's still a lot of weird issues around this stuff in the browser.

raxxorrax 7y ago

I am one of those guilty people that still use jQuery since I am used to its syntax compared to web-api. I also think it has a better syntax. While it is true that I can format dates, I would be unsure about compatibility. Moment is nice to use and has a good date arithmetic. That would all be possible without third party libraries, but often you want to subtract 2 weeks from a date and that is just a pain in the arse with timestamps. You also might want to import/export dates to databases, which can be picky about the format. I am no web developer, so others might have better opinions. And I think the author is correct that people not used to certain libraries should try the standard ones first.

beatgammit 7y ago
You can always check https://caniuse.com https://caniuse.com for browser compatibility, or the MDN article for whatever feature you're interested in.

wruza 7y ago

A small reminder: internationalization is only one of many operations on dates, and libraries exist because browser api sucks at most of these.

dmitryminkovsky 7y ago

I wonder if this requires you to have locales locally installed? How compatible is this? Recently learned that you can internationalize dates right in your Postgres queries/functions! tps://stackoverflow.com/a/59632278/741970. Postgres has great date functionality in general, but with Linux locales installed you can use it for just about anything date related.

qwerty456127 7y ago

The whole date internationalization thing should be deprecated. Everybody smart enough to use a computer is smart enough to understand ISO 8601 (which is by all means better than any other human-readable way to record a date). I also hate the fact some countries use comma instead of the decimal point (which causes problems often). Keeping these differences alive doesn't seem to serve any good purpose. These things should really be made a part of the metric system.

jeroenhd 7y ago
You're either greatly overestimating the literacy of many computer users or you're choosing to apply some kind of "intelligence filter" to your code if you're serious about this. People like reading nice dates and nice words. They're easy to parse for human brains. Sure, "1e6" is nice and short but typing out "a million" is much easier to understand. Giving someone a notification that they have an appointment "next Thursday (2020-02-27)" is a lot clearer than just stating the date. It saves people from having to look up the current date and doing mental math to find out how much time is in between those dates. Nit everyone is a programmer and not everyone likes short and concise data notation. Date localisation exists for a reason and it's not because people like to make developers' lives impossible. Use ISO8601 because of its technical superiority if you want, but don't think it's the final answer to the date/time problem.
- qwerty456127 7y ago
  > People like reading nice dates How is 2020-02-27not nice? > Sure, "1e6" is nice and short but typing out "a million" is much easier to understand IMHO 1 000 000 is the easiest (sure the 1e6 from is better for bigger numbers). As for "a million" I don't understand anything bigger described this way (billions, trillions etc) - tell me 1 trillion and 2 billions and I have absolutely no idea how much is that. It wouldn't be a problem for me to memorize unless there were not the long and the short system as I rarely have a clue which one is being used. > "next Thursday (2020-02-27)" is a lot clearer than just stating the date Sure, but something like 02.27,2020 is no way better than 2020-02-27, it's just a matter of habit particularly easy to change.