6 ms·

Does this mean I can get rid of moment.js now?

SwiftyBug 6y ago
moment.js is so annoying because if I don't do momentObject.clone() everywhere I end up having many unwanted side-effects.
- flipchart 6y ago
  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
  - ryzokuken 6y ago
    The Temporal API is immutable, so you won't have to deal with it anymore.
- Roboprog 6y ago
  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.
wyattjoh 6y ago
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 https://moment.github.io/luxon/index.html [1]: https://moment.github.io/luxon/docs/manual/moment.html https://moment.github.io/luxon/docs/manual/moment.html
- flipchart 6y ago
  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/ https://jquense.github.io/react-widgets/localization/
  - WorldMaker 6y ago
    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/Reference/Global_Objects/Intl https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- WorldMaker 6y ago
  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/ https://date-fns.org/
mattwad 6y ago
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.
- kcorbitt 6y ago
  Check out https://www.npmjs.com/package/date-fns-tz 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.
  - sratner 6y ago
    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.
jacobr 6y ago
You can already use https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... for quite a few of moment’s use cases.
ryzokuken 6y ago
Not yet, but fingers crossed, it would reach Stage 3 in a few months.

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

flipchart 6y ago
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
- ryzokuken 6y ago
  The Temporal API is immutable, so you won't have to deal with it anymore.
Roboprog 6y ago
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.

wyattjoh 6y ago

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 https://moment.github.io/luxon/index.html [1]: https://moment.github.io/luxon/docs/manual/moment.html https://moment.github.io/luxon/docs/manual/moment.html

flipchart 6y ago
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/ https://jquense.github.io/react-widgets/localization/
- WorldMaker 6y ago
  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/Reference/Global_Objects/Intl https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
WorldMaker 6y ago
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/ https://date-fns.org/

mattwad 6y ago

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.

kcorbitt 6y ago
Check out https://www.npmjs.com/package/date-fns-tz 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.
- sratner 6y ago
  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.

jacobr 6y ago

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

ryzokuken 6y ago

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