I've switched most of my work that used to use moment over to Luxon[0] now. It's still written by the same authors, but fixes a lot of the drawbacks[1].

[0]: https://moment.github.io/luxon/index.html [1]: https://moment.github.io/luxon/docs/manual/moment.html

Luxon is great.

Also, if you find you only really need one or maybe two date time utilities, date-fns [1] is an alternative that that takes an even more modular approach for tinier imports.

[1] https://date-fns.org/

I'm using React Widgets[0] and I prefer moment over Globalize (been through so much pain with this). Maybe it's time to either write a localizer for Luxor or find a new date time picker

[0]: https://jquense.github.io/react-widgets/localization/

Depending on your specific needs [0], a lot of date localization can be done (painfully, but possibly) directly with Browser Intl [1] calls instead of a library.

[0] Current user's current locale is easy. If for some reason you need to show some other locale than what the browser is using you'll likely still need Moment or Globalize.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I've been using date-fns on the backend. It's great; so long as you don't have to deal with timezones, because the functions only accept and return Date objects, which don't support internal timezone. The other day I needed to get the hour of day based on a user's timezone, though. And had to resort to moment-timezone because NO i dont want to have to handle the math on my own.

Check out https://www.npmjs.com/package/date-fns-tz. The API is much less intuitive than the `date-fns` one because javascript Date objects don't store their timezone, but I've used it in a real project and it's workable once you grok the mental model.

Personally, I prefer Luxon's timezone handling. I get the appeal of not providing custom classes, but _actually changing the underlying timestamp_ to adjust for timezone has always caused nothing but trouble for me. It becomes an all-or-nothing system (you must use `date-fns-tz` to manipulate the dates) with nothing to actually enforce that.

moment.js is so annoying because if I don't do momentObject.clone() everywhere I end up having many unwanted side-effects.

I have been lucky, then.

I pulled in moment about 5 years ago into our group’s stack, but we mostly use it for parsing and formatting date (only) strings for date arithmetic. The government vital records forms we are working with seldom deal with time of day, and when they do, it’s an optional string down to minutes resolution only.

I guess all the converting to and from strings coincidentally protected me from mutability. Good to know.

I've been burned by this so many times! Code that uses moment is written, tested, and then never touched to make sure you stay sane

The Temporal API is immutable, so you won't have to deal with it anymore.

You can already use https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... for quite a few of moment’s use cases.

Not yet, but fingers crossed, it would reach Stage 3 in a few months.