Error isn't always thrown when currentDate out of bounds of timespan range

[tonyd33]

Even if currentDate is out of bounds of startDate and endDate, it's possible that we don't throw an error. Here are illustrative examples:

Scenario 1: currentDate is after endDate

const options1 = {
  startDate: new Date('2024-10-01'),
  endDate: new Date('2024-10-07'),
  currentDate: new Date('2024-11-01'),
};

const interval1a = parser.parseExpression('0 1 * * *', options1);
const interval1b = parser.parseExpression('0 1 * * *', options1);
try {
  interval1a.next();
} catch (err) {
  // this is expected
  console.log("Error on interval1a.next()");
}
// but calling prev() won't throw even though currentDate is out of bounds
// and the date returned from this isn't even clamped to the endDate
interval1b.prev();
console.log("No error on interval1b.prev()");

Scenario 2: currentDate is before startDate

const options2 = {
  startDate: new Date('2024-10-01'),
  endDate: new Date('2024-10-07'),
  currentDate: new Date('2024-09-01'),
};
const interval2a = parser.parseExpression('0 1 * * *', options2);
const interval2b = parser.parseExpression('0 1 * * *', options2);
// this doesn't throw even though currentDate is out of bounds
// and the date returned from this isn't even clamped to startDate
interval2a.next();
console.log("No error on interval2a.next()");
try {
  interval2b.prev()
} catch (err) {
  // this is expected
  console.log("Error on interval2b.prev()")
}

I think this is bound to cause some troubles or confusion. It certainly did for me, although that was partly because I had confused currentDate with startDate at first. However, that trouble could've been prevented if we threw an error in these out-of-bounds cases.