jkbrzt / rrule

JavaScript library for working with recurrence rules for calendar dates as defined in the iCalendar RFC and more.
https://jkbrzt.github.io/rrule
Other
3.27k stars 506 forks source link

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

Open Zacqary opened 1 year ago

Zacqary commented 1 year ago

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:

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

ebk46 commented 1 year ago

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

nsb commented 10 months ago

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

KrisLau commented 8 months ago

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)