Repository: jkbrzt/rrule

Issue #537: Tests fail when run from TZ=Pacific/Kiritimati
Created: 2022-07-15T18:07:41Z
Reporting an issue
Thank you for taking an interest in rrule! Please include the following in
your report:

 Verify that you've looked through existing issues for duplicates before
creating a new one
 Code sample reproducing the issue. Be sure to include all input values you
are using such as the exact RRule string and dates.
 Expected output
 Actual output
 The version of rrule you are using
 Your operating system
 Your local timezone (run $ date from the command line
of the machine showing the bug)

rrule 2.7.1
macOS Monterey 12.2
Sat Jul 16 07:59:29 +14 2022
Most of the tests will fail with the date being one day in the future when running the tests using the following: TZ=Pacific/Kiritimati npm run test. Mind this is not internally using timezones, but having a machine being in the +14 timezone Pacific/Kiritimati.
Example Output:
  271) rrulestr
       testStrNWeekDay [every year on the 1st Tuesday and last Thursday for 3 times] [DTSTART:19970902T090000Z
RRULE:FREQ=YEARLY;COUNT=3;BYDAY=+1TU,-1TH]:

       - 1/3
      + expected - actual

      -Thu Dec 25 1997 23:00:00 GMT+1400 (Line Islands Time)
      +Fri Dec 26 1997 23:00:00 GMT+1400 (Line Islands Time)
      
      at assertDatesEqual (test/lib/utils.ts:28:59)
      at Context.<anonymous> (test/lib/utils.ts:123:5)
      at processImmediate (node:internal/timers:466:21)

  272) rrulestr
       testStrNWeekDayLarge [every year on the 13th Tuesday and 13th last Thursday for 3 times] [DTSTART:19970902T090000Z
RRULE:FREQ=YEARLY;COUNT=3;BYDAY=+13TU,-13TH]:

       - 1/3
      + expected - actual

      -Thu Oct 02 1997 23:00:00 GMT+1400 (Line Islands Time)
      +Fri Oct 03 1997 23:00:00 GMT+1400 (Line Islands Time)
      
      at assertDatesEqual (test/lib/utils.ts:28:59)
      at Context.<anonymous> (test/lib/utils.ts:123:5)
      at processImmediate (node:internal/timers:466:21)

Duplicate issue #555: Wrong result of the between function when machine local timezone greater than GMT+12
Created: 2022-09-25T21:44:51Z
Hello!
There seems to be an issue with rrule 'between' function results when the local timezone is greater than GMT+12
(e.g. Apia Standard Time  GMT+13 timezone)
Here is the simple script to reproduce this issue:
import rrule from 'rrule';
const { RRule } = rrule;

const startDate = new Date('2021-03-23T10:00:00Z');
const minDate = new Date('2021-03-20T00:00:00Z');
const maxDate = new Date('2021-03-26T00:00:00Z');

const rule = new RRule({
    freq: RRule.DAILY,
    dtstart: startDate,
});

const result = rule.between(minDate, maxDate, true);
console.log('result: ', result);
With a local machine's time zone GMT+12 (e.g. Fiji Standard Time) the console output is correct:
result:  [
  2021-03-23T10:00:00.000Z,
  2021-03-24T10:00:00.000Z,
  2021-03-25T10:00:00.000Z
]
But, with a local machine's time zone GMT+13 (e.g. Apia Standard Time), the console output is incorrect:
result:  [ 2021-03-24T10:00:00.000Z, 2021-03-25T10:00:00.000Z ]
2021-03-23T10:00:00.000Z is missing here.

Reporting an issue
Thank you for taking an interest in rrule! Please include the following in
your report:

 Verify that you've looked through existing issues for duplicates before
creating a new one
 Code sample reproducing the issue. Be sure to include all input values you
are using such as the exact RRule string and dates.
 Expected output
 Actual output
 The version of rrule you are using
 Your operating system
 Your local timezone (run $ date from the command line
of the machine showing the bug)


Operating system: macOS 12.4 (Monterey)
Node: v16.15.1
Timezone: Apia Standart Time
RRule version: 2.7.1 (latest)

Closing comment (2022-10-06T16:03:54Z): I've also ran into the same issue. I was using RRule.fromString(rruleInStringFormat) to generate the RRules, but when it comes to obtaining any date with after or between, it starts with a date+1 day (e.g. gives Tuesday where it should give Monday). Funny thing is, that it returns correct hours/minutes, but not the date.
Can it be somehow related to #537 (redundant timezone maths)?