`before`, `between`, `all`, etc. return different times when run in different timezones
Zacqary opened this issue · comments
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.log
ing 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
Having the same issue here. Did you resolve this somehow?
Also having this issue. I would like to get dates in UTC, no matter the local timezone.
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)