possible issue, skipping initial date when tzid and dtstart is provided

[itai-sagi]

Reporting an issue

Hi, I have tried switching from UTC based RRule interval generation to a timezone based as it handles some edge cases, however, while doing the move, I noticed that the first time interval is different.

import {Frequency, RRule, Options} from "rrule";

process.env.TZ = 'UTC';

const toDate = `2024-05-14 06:59:59.999+00`; // corresponds with end-of-day in America/Los_Angeles timezone

const frequencyRuleWithTz: Options = {
    tzid: 'America/Los_Angeles',
    byhour: 5,
    count: 1,
    dtstart: new Date(toDate),
    freq: Frequency.DAILY,
} as any;

const frequencyRuleOld: Options = {
    tzid: 'UTC',
    byhour: 12,
    count: 1,
    dtstart: new Date(toDate),
    freq: Frequency.DAILY,
} as any;

let rrule = new RRule(frequencyRuleWithTz as any);

for (const date of rrule.all()) {
    console.log("America/Los_Angeles");
    console.log(date.toISOString());
}

rrule = new RRule(frequencyRuleOld as any);

for (const date of rrule.all()) {
    console.log("UTC");
    console.log(date.toISOString());
}

Output:

America/Los_Angeles
2024-05-15T12:00:00.999Z

UTC
2024-05-14T12:00:00.999Z

the reason why I expected it would be a seemless migration is because UTC 12 PM <=> LA 5 AM (excluding daylight savings), but instead, the 1st iteration is a day after.

this is the value I expected while providing frequencyRuleWithTz

2024-05-14T12:00:00.999Z

I am not sure if that's the expected behavior, but on this case - it does seem like a bug.

• [x] The version of rrule you are using [2.8.1, also reproduced using 2.7.0]
• [x] Your operating system [ macOS ]
• [x] Your local timezone (run $ date from the command line of the machine showing the bug) [ node process is UTC ]