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
No questions - just a huge thanks for doing this!
Luxon – A library for working with dates and times in JS
41–50 of 80 posts
Re: Luxon – A library for working with dates and times in JS
#42Luxon 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
First 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'})Re: Luxon – A library for working with dates and times in JS
#43Re: Luxon – A library for working with dates and times in JS
#44Luxon 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
First 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'})
Thanks!
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.
Re: Luxon – A library for working with dates and times in JS
#45So 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 I…
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.
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.
Re: Luxon – A library for working with dates and times in JS
#46Re: Luxon – A library for working with dates and times in JS
#47Luxon 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
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
Re: Luxon – A library for working with dates and times in JS
#48Earlier quoted context omitted.
If you only want timezone conversions I removed everything else from Moment. It's less than 2KB uncompressed: https://github.com/scorredoira/timezone.js
I my experience the actual timezone information is the heaviest portion of the payload. I can't wait until all browsers have support for `Intl`
That any computers talk to each other about time in any other terms than epoch is insane to me. From there, converting it to local time zone is pretty easy, but it should be a presentation-layer ONLY thing. If you’ve ever worked with or implemented a system where this wouldn’t work, I’m interested in hearing about why.
Re: Luxon – A library for working with dates and times in JS
#49Earlier quoted context omitted.
Can you elaborate?
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.
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
EDIT: the official “kibibyte” was standardized in 1998: https://physics.nist.gov/cuu/Units/binary.html so almost 20 years ago. Blame Windows and HDD mfgs for sticking with the SI definitions.
Re: Luxon – A library for working with dates and times in JS
#50Earlier quoted context omitted.
First 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'})
Thanks! 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…
You want HebCal for that. Open source! Has an API available, too!