9 ms·
Luxon – A library for working with dates and times in JS
- bastijn 9y agoNot 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 9y agoThere'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 9y agoThanks. 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 9y agoWell, perhaps the people who don't care to investigate just aren't a target of this library at the moment.
- hectorlorenzo 9y ago"at the moment"? No pun intended?
- icambron 9y agoIt is linked on the Github page. There's also a link to a page making direct feature comparisons to Moment: https://moment.github.io/luxon/docs/manual/faq/moment.html https://moment.github.io/luxon/docs/manual/faq/moment.html
- dwg 9y agoFor me and I'm sure others one of the most important differences is immutability. This has been a big request from the community, but would be impossible to implement in moment without breaking much code which relies on the current mutability. https://github.com/moment/moment/issues/1754 https://github.com/moment/moment/issues/1754
- k__ 9y agoHow does it compare to date-fns?
- hobofan 9y agoBiggest 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.
- tommikaikkonen 9y agoI'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 9y agoYes, 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.
- cel1ne 9y agoPLEASE 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.
- deleted 9y ago[deleted]
- jazoom 9y agoWhat 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.
- to3m 9y agohttps://js-joda.github.io/js-joda/cheat-sheet.html https://js-joda.github.io/js-joda/cheat-sheet.html EDIT: My precious internet points! ;) - wait, is this not a page of examples, as linked to from the GitHub page?
- jazoom 9y agoI think you might be downvoted because you plastered a link with no explanation. It doesn't actually address my concern, which was that when I was reading the documentation I did not see any examples.
- devty 9y agoAgree 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 9y ago
- ianstormtaylor 9y agoHow does this compare in file size to Moment? That's the only real issue I have with it.
- pygy_ 9y agoAfter 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 9y agoTIL they just completely redefined a kilobyte a while ago.
- orf 9y agoCan you elaborate?
- collectively 9y agoAt 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 9y agoHard 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 9y ago
- jazoom 9y agoInteresting. It looks like this is maintained by the maintainers of moment.
- bshimmin 9y agoMonths 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 9y agoI 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 9y agoNo, 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 9y agoGood stuff.
- frutiger 9y agoI'm not defending the difference between how months and days/years are treated. But here are some possible reasons. From ctime(3): Broken-down time is stored in the structure tm, which is defined in <time.h> as follows: struct tm { int tm_sec; /* Seconds (0-60) */ int tm_min; /* Minutes (0-59) */ int tm_hour; /* Hours (0-23) */ int tm_mday; /* Day of the month (1-31) */ int tm_mon; /* Month (0-11) */ int tm_year; /* Year - 1900 */ int tm_wday; /* Day of the week (0-6, Sunday = 0) */ int tm_yday; /* Day in the year (0-365, 1 Jan = 0) */ int tm_isdst; /* Daylight saving time */ }; Also, it allows you to do things like ["JAN", "FEB", ..., "DEC"][theDate.month]
- 9y ago
- rplnt 9y agoSorry 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?
- foota 9y agoFrom what I've seen JavaScript's standard library doesn't change much, most the changes are language changes? As for what it adds, looks like duration and interval classes.
- icambron 9y agoThe 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.
- feiss 9y agoFunny. All libraries/frameworks nowadays qualify themselves as 'modern'.
- ryenus 9y agoSo 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.
- notaboutdave 9y agoThis 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 9y agoFor 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 9y agoHave you tried date-fns (http://date-fns.org/ http://date-fns.org/)? One good thing is that they bundle every module separately, so you can only import what you need.
- neals 9y agoIn what situation is immutable important?
- raspasov 9y agoDates 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.
- dbg31415 9y ago* The Problem with Time & Timezones - Computerphile - YouTube || https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
- icambron 9y agoLuxon 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
- nevir 9y agoNo questions - just a huge thanks for doing this!
- notaboutdave 9y agoFirst of all, thanks for sharing your great work. The support for non-Gregorian output is interesting. Are there any plans to extend full support beyond Gregorian? For example, something like: dt.plus({months: 7, calendar: 'hebrew'})
- icambron 9y agoThanks! No, there's no plan to do that. The trouble is that Luxon has no idea how the Hebrew calendar works; it only knows how to output the non-Gregorian stuff because your browser already can via the Intl.DateTimeFormat API. Luxon finds some interesting ways to abuse that API to add some neat features like internationalized parsing and full time zone support, but there's a limit there. To add 7 Hebrew months, Luxon would actually have to be able translate arbitrary Hebrew dates into timestamps, and I can't think of a way to make it do that without any real knowledge of the calendaring system.
- Asparagirl 9y agoYou want HebCal for that. Open source! Has an API available, too! http://www.hebcal.com/home/developer-apis http://www.hebcal.com/home/developer-apis
- seanp2k2 9y agoWhen 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
- tobyhinloopen 9y ago2017. 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
- lolc 9y agoAh, 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.