`before`, `between`, `all`, etc. return different times when run in different timezones

[Zacqary Adam Xeper]

In RRule 2.7.2 (but also reproduced as far back as 2.6.4), spin up a Jest environment and run the following:

describe('repro', () => {
  // To pass, set the timezone to the equivalent tzid of the RRule.
  // In alerting/jest.config.js, before module.exports, we can set the timezone:
  //
  // process.env.TZ = 'CET';
  // Or execute Jest with TZ="CET"
  //
  // To fail, change the TZ to anything else, such as UTC, Asia/Taipei, or America/New

  it('start', () => {
    // Set the current time as:
    //   - Feb 27 2023 08:15:00 GMT+0000
    jest.useFakeTimers().setSystemTime(datetime(2023, 2, 27, 8, 15, 0));

    const dtstart = datetime(2023, 2, 25, 0, 0, 0);

    const testRule = new RRule({
      byweekday: [RRule.SA],
      freq: RRule.WEEKLY,
      tzid: 'Europe/Madrid',
      interval: 1,
      dtstart,
    });

    const result = testRule.before(new Date(), true);

    expect(result?.getTime()).toBe(dtstart.getTime());
  });
});

The reason this is happening is because before seems to be calculating the recurrence time in the local system time, and then just plopping those raw values into a UTC date. When console.loging result:

• If TZ=CET: 2023-02-25T00:00:00.000Z (Feb 25 2023 at midnight, UTC)
• If TZ=UTC: 2023-02-24T23:00:00.000Z (Feb 24 2023 at 11pm, UTC)
• If TZ=Asia/Taipei: 2023-02-25T07:00:00.000Z (Feb 25 2023 at 7am, UTC)

And the corresponding getTime() call results in different Unix timestamps. Calling getTimezoneOffset() also produces a non-zero offset when you run the test outside of UTC, in contrast to what the README indicates.

Note that removing the tzid from the RRule does not help the situation

[Evan Kesten]

Having the same issue here. Did you resolve this somehow?

[Niels Sandholt Busch]

Also having this issue. I would like to get dates in UTC, no matter the local timezone.

[Kris]

Did anyone figure this out? Recurring events (MWF for example) created in timezones outside of the US (Asia/Singapore) are creating dates with the incorrect days (becomes SU, TU, TH)