
Luxon – A library for working with dates and times in JS - kermire
https://github.com/moment/luxon
======
ryenus
So it's a better moment made by the moment team:

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

~~~
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

------
icambron
Luxon author here, happy to answer anything.

Edit: Here's a thing I wrote about why this exists:
[https://moment.github.io/luxon/docs/manual/faq/why.html](https://moment.github.io/luxon/docs/manual/faq/why.html)

~~~
seanp2k2
When can you make a Python version available? Datetime is by far my biggest
gripe with Python. It takes many times the lines of code to do something
“simple” with it vs other languages (e.g. parse remote time stamp in a
specific format, apppend time zone info to that, get local time + zone,
normalize both to UTC, compare, present difference in human-readable format).

Here’s the python version of moment:
[https://github.com/zachwill/moment/blob/master/README.md](https://github.com/zachwill/moment/blob/master/README.md)

~~~
BrandoElFollito
Have you tried arrow (my favorite), dolorean or a third one the name escapes
me right now?

I use arrow whenever I need to process a date, no matter the usage. Having a
consistent interface is golden.

EDIT I just realized that the author of moment in Python (you link to) also
mentions arrow. I have to remember the name of the third package, it addressed
some weaknesses in arrow (particularly issues with failed parsing which does
not output an error)

~~~
maxerickson
Possibly
[https://github.com/kennethreitz/maya](https://github.com/kennethreitz/maya)

~~~
BrandoElFollito
I remember, it was Pendulum,
[https://github.com/sdispater/pendulum/](https://github.com/sdispater/pendulum/)

------
tommikaikkonen
I've migrated a lot of code from moment to date-fns because of moment's bulky
size and vast, mutable API. Luxon seems to fix the API issue. date-fns is
still great for simple operations, but I'll definitely consider this for new
projects with nontrivial datetime handling.

~~~
spraak
Yes, mutation in Moment has burned me a few times before I realized that
occurs.

Edit: wow, I just looked at the repo and realized its made by the Moment team.
That might be pretty cool.

------
ianstormtaylor
How does this compare in file size to Moment? That's the only real issue I
have with it.

~~~
pygy_
After minification with Uglify:

27.3 KB compressed with `gzip -9`, 26.4KB with `zopfli -i1000` and 24.0KB with
`brotli -q 11`.

(kilo, not kibi)

~~~
collectively
TIL they just completely redefined a kilobyte a while ago.

~~~
orf
Can you elaborate?

~~~
collectively
At some point, a kilobyte was 1024 bytes. Now, a kilobyte is 1000 bytes, and
1024 bytes is a kibibyte.

I mean, it does make sense. But it just sounds off to me.

~~~
seanp2k2
Hard drive manufacturers have been doing this for decades. This is why the
“80GB” drives were 74.5GB in Windows.

It’s more complicated with SSDs:
[https://www.anandtech.com/show/2829/7](https://www.anandtech.com/show/2829/7)

EDIT: the official “kibibyte” was standardized in 1998:
[https://physics.nist.gov/cuu/Units/binary.html](https://physics.nist.gov/cuu/Units/binary.html)
so almost 20 years ago. Blame Windows and HDD mfgs for sticking with the SI
definitions.

~~~
sd8dgf8ds8g8dsg
Yea, bad bad windows for following standards.

The SI prefixes are well established before 1998 and the cause for this
brainmelt.

[https://en.wikipedia.org/wiki/Metric_prefix](https://en.wikipedia.org/wiki/Metric_prefix)

~~~
CodesInChaos
Windows (at least up to 8) does not follow the SI standard. It uses KB, MB, GB
but converts using 1024. Which has funny consequences, like 999MB being
smaller 0.94GB.

------
bshimmin
_Months in Luxon are 1-indexed instead of 0-indexed like in Moment and the
native Date type._

This seems like a bold decision and terrifying source of errors for those of
us with decades of experience thinking January is 0.

~~~
hectorlorenzo
I think that moment.js was already built that way. For me it kinda makes
sense: if days are calculated with a 1-index in mind, why make months
different? As I said: it KINDA makes sense.

~~~
icambron
No, they're 0-indexed in Moment. But yes, the reason I made Luxon 1-index them
is that days and years are 1-indexed. I also fielded a _lot_ of issues in
Moment that were caused by newer programmers not knowing that months were
0-indexed.

~~~
hectorlorenzo
Good stuff.

------
bastijn
Not a direct js dev so forgive my ignorance. How does this compare to
moment.js [0]? Any feature differences?

[0] [https://momentjs.com/](https://momentjs.com/)

~~~
Osmose
There's a page explaining this:
[https://moment.github.io/luxon/docs/manual/faq/why.html](https://moment.github.io/luxon/docs/manual/faq/why.html)

~~~
bastijn
Thanks. This link should be on the github page to be honest. For people like
me who do not (always) click through if they don’t see an immediate need. Only
now notice the url contains moment and this is part of moment.

~~~
Techonomicon
Well, perhaps the people who don't care to investigate just aren't a target of
this library at the moment.

~~~
hectorlorenzo
"at the moment"? No pun intended?

------
lolc
Ah, immutable. Mutability is my biggest issue with Moment.js. It seems they
have kept the API mostly the same, so this will be easy to replace.

------
jazoom
Interesting. It looks like this is maintained by the maintainers of moment.

------
k__
How does it compare to date-fns?

~~~
hobofan
Biggest remaining difference I can see is that Luxon still has it's own
classes while date-fns operates on bare DateTime objects (AFAIK), which allows
for a different kind of API. So it's mostly a matter of personal preferences
now.

------
feiss
Funny. All libraries/frameworks nowadays qualify themselves as 'modern'.

------
dbg31415
* The Problem with Time & Timezones - Computerphile - YouTube || [https://www.youtube.com/watch?v=-5wpm-gesOY](https://www.youtube.com/watch?v=-5wpm-gesOY)

------
rplnt
Sorry for the dumb questions, I haven't worked with js much, but what does
this add to the standard library?

Going just by the one example there, I can see that timezone by location is
probably extra, that's perfectly fine. The endOf modifier seems more like a
helper to fix broken date/time model in js? But other parts should probably be
in the standard library? I was under the impression js is improving fast
nowadays, will stuff like this get into the language?

~~~
icambron
The standard library is really difficult to work with and does very little for
you. There _are_ some improvements to Dates coming through the standards
pipeline but it will be a while.

------
tobyhinloopen
2017\. We have async, promises, classes, => functions in Javascript, but we
still have abysmal date & time support and 100 libraries to solve it.

This library looks less bad than momentJS' tangled ball of mud. Good job

------
cel1ne
PLEASE use joda-js on Javascript: [https://js-joda.github.io/js-
joda/](https://js-joda.github.io/js-joda/)

It's a port of the java8 date/time API, which is the most correct date-
handling library there is.

~~~
jazoom
What if one does not want to use a port of Joda? Even looking at the
documentation makes me run away. Where are all the examples?

date-fns seems good, moment works well too, despite its flaws, this new one is
worth looking at.

Dismissing all other libraries isn't very helpful.

And yes, I realise all other libraries are wrappers around Date. It works well
enough for 99% of cases.

~~~
devty
Agree with your points, but I really thought joda-time’s documentation was
decent! Cheatsheet had plenty of examples: [https://js-joda.github.io/js-
joda/cheat-sheet.html](https://js-joda.github.io/js-joda/cheat-sheet.html)

~~~
jazoom
Thanks. I didn't find that last time. Examples should really be in the actual
documentation.

