
You don't need libraries for internationalization of dates - patelpankaj
https://time2hack.com/you-dont-need-libraries-for-internationalisation-i18n-of-dates/
======
patelpankaj
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
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.

------
oftenwrong
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
[https://github.com/github/time-elements](https://github.com/github/time-
elements)

~~~
sli
My first thought reading the parent comment was indeed that WebComponents
would be perfect for this. Thanks for the link.

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

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

------
joekrill
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
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
You can always check [https://caniuse.com](https://caniuse.com) for browser
compatibility, or the MDN article for whatever feature you're interested in.

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

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

~~~
tlarkworthy
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_
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
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
You don't need to send ICU4C to the user however, you can depend on it already
being installed.

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

------
janpot
Also see [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat)

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

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

~~~
imron
Preferably installed on a kubernetes cluster so that it can automatically
scale.

~~~
randomdude402
Definitely on AWS, because if it's not on AWS, is it really even in the cloud?

------
fake-name
(In javascript, because you can standard _library_ ).

So yes, you do.

~~~
virtue3
also, for the love of God, if you do any sort of date manipulation, just suck
it up and use moment.

~~~
untog
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
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.

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

~~~
jeroenhd
> How is 2020-02-27 not nice? It's an uncommon way to denote date. If you're
> used to the usual date notations (day before month) you can easily get
> confused with dates like 2020-03-04. Sure, the first number is the year, but
> what do the other two numbers mean? Maybe the order is clear if you're used
> to the American way of denoting dates (month before day) but only a small
> minority of people worldwide use that.

Habits are not easy to change and changing them gets harder as you get older.
Microsoft changing the icon of the start menu got me many questions from
people anywhere between 20 and 80 back when I did tech support. These people
were smart enough to use a computer yet a tiny change confused them. When
Windows changed their start menu to something new, people didn't want to
change the way they did things and tools like Classic Start was born. If
clicking an icon on a computer is too hard a habit to change, how do you think
telling the world to change their date notation will go down?

And why should we all go do stuff differently because someone has come up with
a way that makes lexicographical sorting of dates possible?

Furthermore, "next Thursday" is already part of internationalisation code
(Thursday needs to be translated and the concept of what the literal
translation of "next Thursday" means changes between languages and cultures).
Why not also put the full date into the correct locale as well while you're at
it?

Just because I think metric measurements are superior to imperial measurements
doesn't mean I don't need to translate those units of measurement to American
when I publish an app that uses them. Anyone capable of counting to ten can
understand the metric system but that doesn't mean I can get away with
providing metric-only information and input fields for everything.

There's a difference between what academics and engineers use and what the
general public uses. If you don't make a general product for the general
public then you don't make a very good product.

~~~
jiggawatts
> It's an uncommon way to denote date.

It's a _very_ common way to denote date, and you would have to be borderline
retarded to not understand it.

> If you're used to the usual date notations (day before month)

This is not _usual_ at all! You've just handwaved away the #1 stupidity of
localized date formats: the special flower that is the United States and their
crazy M/D/Y shorthand that means that nobody can ever parse these "common"
date formats unambiguously, anywhere. Not humans, not computers, not even
hyper intelligent AIs of the future. Critical information is being thrown
away, and can never ever be recovered.

> Habits

What habits? I just assume that any site showing me a date like 3/4/5 could be
either the 4th of March or April 3rd. It's like a Quantum Date, in a
superposition of possibilities. That's the habit I'm currently used to.

If you're not confused, then you probably live in the US, which is a 4.25%
minority of the world population, so it's a small group that I think we all
agree can be safely ignored.

> And why should we all go do stuff differently because someone has come up
> with a way that makes lexicographical sorting of dates possible?

Why would you _not_ "do stuff" when _as a bonus_ you get trivially sortable
dates _on top_ of having unambiguous dates that both humans and computers can
interpret correctly?

Doesn't it drive you crazy that randomly things just _don 't work_ because
some twat left a Windows servers on en-US so that CSV export or import just
shreds data? Or if you're in the states, you get data sent to you and you
can't figure out why there are sales in the future? Doesn't it drive you crazy
that when you see a security hotfix saying 3/4/5 you have no idea if it's next
month or the month after?

> Clicking an icon on a computer is too hard a habit to change

It isn't, people just like to whine.

One of the few smart CIOs once told me: Don't worry about the icon changing.
Don't even bother telling anyone. We're not paying $100K to people too
retarded to do their job because the colour of the icon changed.

> metric-only information and input fields for everything.

This actually happens all the time, and people figured it out without their
brains leaking out of their ears.

What _nobody_ can get used to is a single number on a webpage showing a
measurement _without units_.

If I tell you to buy a "5" screw or dig a "7 deep hole", you would have _no
clue_ what that means. You _can 't possibly_. No matter what.

A date in a format like 3/4/5 is exactly the same thing: meaningless numbers
without units or context.

A date in the format of 2020-04-03 or 2020-03-04 have only one interpretation.

> There's a difference between what academics and engineers use and what the
> general public uses.

Yeah well, academics came up with the Metric system and 95.75% of the world
population _loves_ it.

