[ryenus]

So it's a better moment made by the moment team:

https://moment.github.io/luxon/docs/manual/faq/moment.html

Major differences:

  * Immutable
  * Months in Luxon are 1-indexed instead of 0-indexed like in Moment and the native Date type.
  * Localizations and time zones are implemented by the native Intl API (or a polyfill of it), instead of by the library itself.
  * Luxon has both a Duration type and an Interval type. The Interval type is like Twix.
  * Luxon lacks the relative time features of Moment and will until the required facilities are provided by the browser.

[notaboutdave]

This is an excellent rewrite, but I'm hesitant to try it because Moment doesn't emphasize speed.

I'm in need of a fast date and time library (close to realtime) and have reluctantly rolled my own until I find a better option.

[icambron]

For what it's worth, there's no code (edit: well, maybe a few lines) in common between the libraries; Luxon is written from scratch. I haven't done a ton of perf testing, but depending on your use case, I'd expect most operations to be much faster in Luxon. The caveat there is that Moment objects are mutable, which can sometimes be a perf advantage.

[tonyhb]

Have you tried date-fns (http://date-fns.org/)? One good thing is that they bundle every module separately, so you can only import what you need.

[neals]

In what situation is immutable important?

[icambron]

I think there are lots of good reasons to make datetimes immutable (e.g. many of the same reasons most languages make strings immutable). But here's one specific to Moment and Luxon: chainable APIs should really always have immutable types because the return value is the thing you use next anyway. When each call returns an instance of the type it's both completely unnecessary and very often harmful for those calls to modify anything.

  var a = moment();
  console.log("the end of tomorrow is", a.add(1, 'day').endOf('day'));

  // do more stuff with a
  // oh crap, a is now set to tomorrow? wtf?

If you want a to be the end of tomorrow, all you needed to do was assign a to the whole chain, so this mutation didn't help you. That add() and endOf() return instances of Moment signals that they are Moment -> Moment functions, not mutators that also return the object. A mutable API should have void methods:

  var a = moment();
  a.add(1, 'day');
  a.endOf('day');

  // do stuff with a

[raspasov]

Dates and times are values by definition, not mutable objects that can be changed via methods. The year 2017 is 2017. It represent a moment in time, or more precisely a period of time between two points. The year 2017 does not “become” 2018 when you .add one year to it. Fully immutable objects are also easier and simpler to compare since they are, again, values. 2017 is 2017, always. Not using proper immutability leads to an “object identity” crisis where everything is anything. An infinite amount of years 2017 are allowed to exist by default(!) and they are not easily comparable or require specific library APIs to allow that.

[bmn__]

Mutability invites bugs, so immutability is important in the general case, not in special situations.

https://rjbs.manxome.org/rubric/entry/1929

https://blog.plover.com/prog/perl/DateTime-Moonpig.html