fix: stop hour-step loop early on spring-forward DST days to prevent day skip

[malenkov]

Bug

On spring-forward DST transition days, next() skips the entire day when the cron expression targets that day via day-of-week, returning the following week instead.

Minimal repro (US spring-forward, March 8 2026):

const { CronExpressionParser } = require('cron-parser');

const interval = CronExpressionParser.parse('0 8 * * 0', {
  tz: 'America/Chicago',
  currentDate: new Date('2026-03-08T05:45:00.000Z'), // 11:45 PM CST Sat Mar 7
});

console.log(interval.next().toISOString());
// Expected: '2026-03-08T13:00:00.000Z'  (8am CDT Sun Mar 8)
// Got:      '2026-03-15T13:00:00.000Z'  (skips DST day, returns following Sunday)

Root Cause

In #matchHour (CronExpression.ts), when the current date falls on a DST transition day, the code steps hour-by-hour instead of directly setting the target hour. The number of steps is computed as nextHour - currentHour in local wall-clock time.

On a spring-forward day, one applyDateOperation(Add, Hour) call jumps 2 wall-clock hours (e.g. 01:00 → 03:00), so the loop overshoots the target by 1 hour:

• Steps calculated: 8 - 0 = 8
• i=0: 00:00 → 01:00
• i=1: 01:00 → 03:00 ← DST jump (2 hours)
• i=2..6: 03→04→05→06→07→08
• i=7: 08:00 → 09:00 ← overshoot!

Now at 09:00, findNearestValue(9) on [8] returns null → the code jumps a full day → repeats until the next Sunday.

Fix

Break out of the stepping loop as soon as the current hour reaches or passes the target:

for (let i = 0; i < steps; i++) {
  currentDate.applyDateOperation(dateMathVerb, TimeUnit.Hour, hours.length);
  // On spring-forward days, one step can jump 2 wall-clock hours and overshoot.
  if (!reverse && currentDate.getHours() >= nextHour) break;
  if (reverse && currentDate.getHours() <= nextHour) break;
}

Tests

Added a regression test in CronExpressionParser.test.ts covering this exact scenario. All 264 existing tests continue to pass.

[harrisiirak]

Hi @malenkov!

I've left some comments, but the PR looks good to me in general.

[harrisiirak]

nitpic: Adding comment overshoot protection is probably fine enough

[malenkov]

Done, shortened to a one-liner.

[harrisiirak]

suggestion: Let's also add reverse direction test case to ensure that it works in both ways.
suggestion: Rename it to "does not overshoot target hour on spring-forward DST day" or something similar

[malenkov]

Done, renamed both tests and added a reverse direction case.

[harrisiirak]

nitpick: Probably don't need that long comment about the behavior, it's rather self explaining already.

[malenkov]

Done, trimmed.