[RAM] Snooze end time shows 1 day ahead of actual end time

[JiaweiWu]

From the SDH: https://github.com/elastic/sdh-kibana/issues/3588

A user noticed their snooze end time is 1 day after the actual end time. The user is in the CET timezone, which is GMT+1 I am able to reproduce this issue using a unit test. In the test below I have simulated the date that was reported in the SDH:

import { getRuleSnoozeEndTime } from './is_rule_snoozed';
import moment from 'moment';

describe('repro', () => {
  // To reproduce, first we must set the timezone to the customer's timezone, 
  // In alerting/jest.config.js, before module.exports, we can set the timezone:
  // 
  // process.env.TZ = 'CET';

  it('start', () => {
    // Set the current time as: 
    //   - Feb 27 2023 08:15:00 GMT+0000
    jest
      .useFakeTimers()
      .setSystemTime(new Date('2023-02-27T08:15:00.000Z'));

    // Try to get snooze end time with:
    //   - Start date of: Feb 24 2023 23:00:00 GMT+0000
    //   - End date of: Feb 27 2023 06:00:00 GMT+0000
    //     - Which is obtained from start date + 2 days and 7 hours (198000000 ms) 
    const result = getRuleSnoozeEndTime({
      muteAll: false,
      snoozeSchedule: [
        {
          "duration": 198000000,
          "rRule": {
            "byweekday": [
              "SA"
            ],
            "tzid": "Europe/Madrid",
            "freq": 2,
            "interval": 1,
            "dtstart": "2023-02-24T23:00:00.000Z"
          },
          "id": "9141dc1f-ed85-4656-91e4-119173105432"
        }
      ]
    });
    
    // In theory, the snooze should be over now, this should pass but it does not.
    expect(result).toEqual(null);

    // Instead we get: 
    //
    // expect(received).toEqual(expected) // deep equality
    // Expected: null
    // Received: 2023-02-28T05:00:00.000Z
    //

    // If we try to log what we see on the front end snooze tooltip, we get the 
    // same bug that the customer noticed (snooze for a day)
    //
    // console.log(moment(result).fromNow(true));
  });
});

I looked in our snooze code and I think the before call from is_snooze_active line 43 is giving us the wrong result:

const lastOccurrence = recurrenceRule.before(new Date(now), true);

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[Zacqary]

Just started investigating but this is probably related to the fact that this rule is supposed to start on Friday February 24th and recur every Saturday.

It’s checking for the end of the “last occurrence” when a new occurrence begins one hour after the snooze is supposed to start. We’ve got two overlapping occurrences.

[Zacqary]

Yeah so shifting the start time forward by an hour makes this pass successfully. Seems like there's an issue related to time zones not taking days of the week into account correctly, I'll work on a fix.

[Zacqary]

Test also fails if we set the date to March 6th UTC. It looks like RRule isn't converting dtstart times to the provided tzid

According to jkbrzt/rrule#501 this may actually be the correct behavior, as per the spec? But the library doesn't follow the spec? I'm not sure. Seems like the library is actually following the spec as far as weekdays are concerned

[Zacqary]

Okay so I have found out what's happening. rrule.js does not respect the Z part of ISO date strings. Its only understanding of timezone is from the tzid and throws out any timezone information that's included in dtstart.

I think this is actually RRule spec compliant, it's just super weird in Javascript. We basically need to treat the Date objects that rrule.js generates for us as if they're strings in the local timezone, and we can't rely on them for accurate unix timestamps.