This seems like a bold decision and terrifying source of errors for those of us with decades of experience thinking January is 0.
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 */
};
["JAN", "FEB", ..., "DEC"][theDate.month]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.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.
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?
var a = moment();
a.add(1, 'day');
a.endOf('day');
// do stuff with aEdit: Here's a thing I wrote about why this exists: https://moment.github.io/luxon/docs/manual/faq/why.html
Here’s the python version of moment: https://github.com/zachwill/moment/blob/master/README.md
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)
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'})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.
27.3 KB compressed with `gzip -9`, 26.4KB with `zopfli -i1000` and 24.0KB with `brotli -q 11`.
(kilo, not kibi)
API looks better than moment though.
It's a port of the java8 date/time API, which is the most correct date-handling library there is.
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.
EDIT: My precious internet points! ;) - wait, is this not a page of examples, as linked to from the GitHub page?
You can built syntactic sugar around js-joda too.
I develop Java/kotlin as well, so I'm used to the API. It feels verbose, but it makes a lot of sense. Date-handling is complex, a library shouldn't hide that.
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?
As for what it adds, looks like duration and interval classes.
Edit: wow, I just looked at the repo and realized its made by the Moment team. That might be pretty cool.
This library looks less bad than momentJS' tangled ball of mud. Good job