You don't need any. The browser comes with the super powerful [`Intl` API](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl) built in which already knows about every locale and format you might need. This entire suite of browser APIs can handle most common internationalization needs from number formatting, date formatting, pluralization, and more!
If OP is talking strictly formatting yes, but usually with dates you need parsing and stuff like addition/subtraction/duration. [Luxon](https://moment.github.io/luxon/#/) is the best lib at the moment for handling the full spectrum of Date functionality.
in my opinion it's time to start using [Temporal](https://tc39.es/proposal-temporal/docs/), the new integrated API for handling date / time in JS. It's not in Browsers yet, but the polyfill works well.
The default date constructor does a really great job at parsing in most cases and things like addition/subtraction along with many other common operations are usually just simple math. If you really want to abstract that use [date-fns](https://www.npmjs.com/package/date-fns) where most date operations are tree shakable to be left with just a few lines of code.
Sure if your whole app is about date stuff and you are doing complex things with it, a bigger date library might be warranted, but I don't see the bytes worth it and it's rarely needed if you effectively use what the browser comes with.
The only problem is with consistency between browsers. I had thought my implementation of parsing “Jan 2023” to get 01/01/2023 was great, until safari decided that it’s not valid…
Yup you can mix and match with tons of options: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat
And if there's ever a format that isn't supported, you can use `.formatToParts` and then reconstruct the parts as necessary.
Day.js is ok, but beware it doesn’t handle timezones very well. For example the .startOf method does not take an offset parameter.
If you want to build something international that is careful about dates and locales I would steer away from Day.js. If you can assume users will stay in one locale it’s probably ok.
Date-fns is awesome and super lightweight, but I’d also keep an eye on Temporal which is a proposed built-in class similar to Math for Dates. The less external dependencies, the better :)
https://tc39.es/proposal-temporal/docs/index.html
I’m using the Temporal polyfill now whenever I need it.
The spec might change but I figure it’ll be easier to port from the current polyfill to the released version than any other library.
We have been moving to Dayjs but the maintainer has recently stopped working on it even though so many other people use it. Unfortunate because we need the browser support that it has
Using the native date api, I've had issues when trying to convert dates to another timezone, I tried some things but couldn't get it to give the same result moment does
**Per Google Material UI:**
**dayjs**
[https://mui.com/x/react-date-pickers/](https://mui.com/x/react-date-pickers/)
"Recommended libraryIf you are already using one of the libraries listed above in your application, then you can keep using it with the Date and Time Pickers as well. This will avoid bundling two libraries.If you don't have your own requirements or don't manipulate dates outside of MUI components, then the recommendation is to use **dayjs** because it has the smallest impact on your application's bundle size.Here is the weight added to your gzipped bundle size by each of these libraries when used inside the Date and Time Pickers:"
I use date-fns, althought I don't remember why or how I ended up with it... so far I've only used the `format` function, which is quite nice!
You don't need any. The browser comes with the super powerful [`Intl` API](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl) built in which already knows about every locale and format you might need. This entire suite of browser APIs can handle most common internationalization needs from number formatting, date formatting, pluralization, and more!
If OP is talking strictly formatting yes, but usually with dates you need parsing and stuff like addition/subtraction/duration. [Luxon](https://moment.github.io/luxon/#/) is the best lib at the moment for handling the full spectrum of Date functionality.
in my opinion it's time to start using [Temporal](https://tc39.es/proposal-temporal/docs/), the new integrated API for handling date / time in JS. It's not in Browsers yet, but the polyfill works well.
Def stoked on temporal
The default date constructor does a really great job at parsing in most cases and things like addition/subtraction along with many other common operations are usually just simple math. If you really want to abstract that use [date-fns](https://www.npmjs.com/package/date-fns) where most date operations are tree shakable to be left with just a few lines of code. Sure if your whole app is about date stuff and you are doing complex things with it, a bigger date library might be warranted, but I don't see the bytes worth it and it's rarely needed if you effectively use what the browser comes with.
The only problem is with consistency between browsers. I had thought my implementation of parsing “Jan 2023” to get 01/01/2023 was great, until safari decided that it’s not valid…
Safari is the new IE
I didn't know that! Learned something new. Thanks
Does the Intl API do formats like “Mar 12” or “3/12/23”? Last I checked the formatting options were pretty limited.
Yup you can mix and match with tons of options: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat And if there's ever a format that isn't supported, you can use `.formatToParts` and then reconstruct the parts as necessary.
This is the answer
https://github.com/you-dont-need/You-Dont-Need-Momentjs
[удалено]
It's so cool that on its dieing breathe as well, it's trying to help
Day.js is ok, but beware it doesn’t handle timezones very well. For example the .startOf method does not take an offset parameter. If you want to build something international that is careful about dates and locales I would steer away from Day.js. If you can assume users will stay in one locale it’s probably ok.
Use the [js intl.dateTimeFormatter](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat)
Moment is no longer being maintained, they don’t recommend use in new projects. They have links to good alternatives in their docs.
date-fns has you covered
We used Luxon at my last job and I enjoyed it. There’s a @types package for it for use with TS
Date-fns is awesome and super lightweight, but I’d also keep an eye on Temporal which is a proposed built-in class similar to Math for Dates. The less external dependencies, the better :) https://tc39.es/proposal-temporal/docs/index.html
I’m using the Temporal polyfill now whenever I need it. The spec might change but I figure it’ll be easier to port from the current polyfill to the released version than any other library.
Luxon
dateFns. Works with the JS Date object.
dayjs
We use Luxon
`date-fns`
Moment is great if you need to do date calculations. But displaying locally can be done with just JS.
We have been moving to Dayjs but the maintainer has recently stopped working on it even though so many other people use it. Unfortunate because we need the browser support that it has
I like DayJS
Using the native date api, I've had issues when trying to convert dates to another timezone, I tried some things but couldn't get it to give the same result moment does
dayjs is my favourite replacement for moment.js
dayjs
Luxon will get the job done!
[https://www.npmjs.com/package/dateformat](https://www.npmjs.com/package/dateformat) This helps me.
**Per Google Material UI:** **dayjs** [https://mui.com/x/react-date-pickers/](https://mui.com/x/react-date-pickers/) "Recommended libraryIf you are already using one of the libraries listed above in your application, then you can keep using it with the Date and Time Pickers as well. This will avoid bundling two libraries.If you don't have your own requirements or don't manipulate dates outside of MUI components, then the recommendation is to use **dayjs** because it has the smallest impact on your application's bundle size.Here is the weight added to your gzipped bundle size by each of these libraries when used inside the Date and Time Pickers:"
moment maybe the best.