eachDays

Return all dates in a interval of 2 dates. You can pass JSDates, strings SQL or DateTime instances.

eachDays(DateTime.local(2018, 11, 1), DateTime.local(2018, 11, 6))
eachDays(new Date(2018, 11, 1, 0, 0, 0), new Date(2018, 11, 6, 23, 59, 59))
eachDays('2018-11-01', '2018-11-06')

Returns

eachDays('2018-11-01', '2018-11-06', 'DateTime')
eachDays('2018-11-01', '2018-11-06', 'JSDate')
eachDays('2018-11-01', '2018-11-06', 'yyyy-MM-dd') // any custom format

https://gist.github.com/jonathanborges/092467191cef14bcc72a7214ed42c36f

[icambron]

There are a few reasons this function won’t go into Luxon:

1. We don’t do this kind of string-driven dispatch
2. It’s easy to do in userspace
3. It’s too specific to your use case (e.g. why days? Why those particular input types?)

My advice above to use iterate was wrong; we removed iterate a long time ago. But this works:

Interval.fromDateTimes(
  DateTime.fromJSDate(date1).startOf("day"), 
  DateTime.fromJSDate(date2).endOf("day"))
.splitBy({days: 1}).map(d => d.start)

[hktr92]

Wouldn’t lib’s role make our lives easier? In date-fns there is a function eachDayInterval

Please make our lives more easier!

I have a project that heavily relies on date intervals written in PHP. I had to implement a custom Interval class that made an inclusive interval (startDate and endDate to be included) since the native one from PHP wasn’t properly working.

So the final usage was something like this:

$ref = Date::now();
$interval = new Interval($ref->startOfMonth(), $ref->endOfMonth());

forEach ($interval as $date) {
    // ...do stuff
}

Behind the scenes, the Interval::getIterator() (which is called by PHP compiler) did the following:

• build the interval array (and correction of the missing start / end date + passing it to PHP’s DatePeriod class)
• generate an iterafor of a period of 1 day (which returns the DatePeriod class), which is converted from iterator to array
• return the converted array

It was all good and nice, until I found out that it won’t be that reliable compared to Chronos implementation. So I have in mind a rewrite of the component to use (ChronosInterval API)[https://api.cakephp.org/chronos/2.x/class-Cake.Chronos.ChronosInterval.html].

So, how my use case helps Luxon and JS world? Simply because JS (doesn’t have a simple iterator API)[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Iterators_and_Generators] and it would pollute the code pretty much if you want to achieve that one directly in the library (which is, however, doable).

However, one could simply write a wrapper, like I did for another node.js project where I’m using this feature, that does what you need to be done. That wrapper simply does:

import { DateTime, Interval } from 'luxon'

const makeInterval = (startDate: DateTime, endDate: DateTime): DateTime[] => Interval.fromDateTimes(startDate, endDate).splitBy({ days: 1 }).map((d: Interval) => d.start)

export { makeInterval }

This function does the same thing that my Interval class does.

This kind of coding style makes me to enforce library wrappers for my business logic and reuse that logic (e.g. make a provider function that gets the date time in a timezone depending on user’s choice

If there would be any problem in writing code this way, project devs would implement the method directly in Interval class.

I mean, I don’t mind writing code this way, it feels more condensed and it makes me feel pretty safe that this is should an Interval class should behave, giving power tools.

So yeah, libs can ease your life, but it shouldn’t do many things as it would break it, especially when implementation of some features are costlier that others.