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
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.
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."
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.
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.
These differences exist because of the freedom given to everybody about their choice. So countries make their operating standard and citizens follow it.
It is simple to think that this format would work but the people who are not familiar with this format will be completely lost with it. People who are not educated but somehow learnt to follow one format; ask them to learn a new format; it will be so complicated.
This is like arguing that nobody should adopt the meter because each country has their local feet, yards, furlongs, cubits, els, steps, rods, lacters, and canas. I mean think about it: countries decide their units of measurements and their citizens follow it. It's freedom!
Sigh...
You're not even from the United States, so you should full well know how important standardisation is across country borders. There are literally only three countries that haven't adopted metric, zero that haven't adopted the standard 24 hour / 60 minute day, and only four that haven't adopted the Gregorian calendar[1].
So why is it so hard to accept the one consistent date format? Seriously? Why?
Tell you what: If you can tell me which day the following date represents, I'll give you USD 100. Seriously. I'm not even kidding.
But seriously, yes. I am French and write the date as 2009-03-01 and get weird looks.
I work in a French company and some people seem to assume that it is fancy to use a US format for the dates. I refuse to read a document which did not have an obvious format.
Heck, even MAR/01/2020 could be acceptable but why? Why?
There are a myriad of debates in email threads about standardizing on ISO 8601. I would love to see it happen, but I would not hold my breath. People code date formats into their applications and db schemas and many other reasons. In most cases I have seen, people could have used epoch and then simply displayed the date based on the user preference.
This cannot ever work. Give it up. Only the ISO yyyy-mm-dd format is unambiguous.
If a user sees some random date, such as 3/4/xxxx, they have absolutely no way to distinguish if this is in their format or not.
If you're in the US, you might assume that this is in your backwards M/D/Y format, meaning it's April 3rd, and you'd be right much of the time.
However, if you're outside the US, then there are two indistinguishable possibilities:
It's a US server ignoring your time format, so this date represents April 3rd.
OR
It's a server correctly showing you a date in your preferred format, so it's actually the 4th of March.
At a glance, these aren't distinguishable. I easily click through 200-500 pages a day! I'm not going to sit down and try to work out which of those hundreds of pages a day, and thousands of pages a week are designed for humans, or just Americans.
Kinda agree, but I'd phrase it a little differently. There exists a time element already[1]. I'd move that the browsers should allow users to change the display of this element on an element / page / session / computer basis. Often there are two or more timezones that matter for any time (e.g. event local time, user's local time, UTC). Often knowing all of these times instead of just one is useful. Rarely is just one of them at the choice of the website presenting the time useful. This is my use case, there are many more.
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)...
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.
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.
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.
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.
That mostly talks about using other date libraries instead of momentjs, not that you don't need date libraries.
Yes, obviously you can forego DRY and write and maintain a bunch of boilerplate for date manipulation, or write and maintain your own date library, but for most uses itmakes a lot more sense to use an existing library. For new uses, probably not momentjs, though—probably date-fns, or luxon, or...
Seems out of date, gziped moment.min.js is only 16.7kb (https://momentjs.com/), which invalidates the main thrust of the argument (i.e. moment is too big).
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.
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.
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.
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.
Moment is huge, its performance sucks and the mutability makes developers shoot themselves in the foot constantly. Trust me there are much better alternatives.
I recently replaced moment (which is huge like others mentioned) with luxon (https://moment.github.io/luxon/). It has pretty much all the same functionality but a way smaller size.
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.
I've used date-fns (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.
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.
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.
> 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.
> 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.
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.
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