Unexpected Breach Time Calculation

[reginabautista]

Hi everyone,

I’m currently working with an SLA Definition (Response SLA) where the relative duration is set to “Next business day by 5 PM”.

Here's the script configured for the Duration Type:

// Next business day by 5pm if before 5pm

var days = 1;

// If the current time is after 17:00, add another day

if (calculator.isAfter(calculator.startDateTime, "17:00:00")) {

    days++;

}

gs.info("days " + days);

calculator.calcRelativeDueDate(calculator.startDateTime, days, "17:00:00");

Configuration Details:

• Schedule: 08:00–17:00, Monday to Friday (No Timezone set)

• User Timezone: Europe/London

• Instance Timezone: Europe/London

Objective

The SLA breach time should be calculated as follows:

1. If the current time is before 5 PM, set the breach time to 5 PM on the next business day.

2. If the current time is after 5 PM, set the breach time to 5 PM on the next business day + 1.

Issue

A user created a ticket on Sunday, February 2, 2025, at 4:57 PM (user timezone: Europe/London).
Expected behavior: Since the ticket was created during the weekend, the SLA should begin from the next business day (Monday), and since the submission was before 5 PM, the breach time should be Tues, February 4, 2025, at 5 PM.

However, the system is calculating the breach time as Wednesday, February 5, 2025, at 5 PM, which is an unexpected additional day.

Could anyone help identify what might be causing this extra day to be added to the breach time?

Appreciate any insights you can share.

Thanks,

Regina

[ivanortiz]

my main hunch is that the time zone ain't spelled out clearly in the Schedule record. Gotta make sure all the bits and pieces – the Instance, the User (if it matters), the Schedule, and the SLA Definition – are all on the same page with the time.

Setting the Time Zone in the Schedule:

Go into that Schedule record you're using for the SLA setup. Look for the "Time zone" field. Properly pick "Europe/London" (or whatever time zone that schedule's supposed to be using). Hit save on that Schedule record. Try making a fresh ticket with the same stuff to see if the time calculation gets its act together.

Throwing Some Logs in the Script: To see exactly what the heck's going on inside that script:

For now, mess with your relative duration script to add some logging:

// Next business day at 5 PM if it's before 5 PM now
var days = 1;
var startTime = calculator.startDateTime; // Saving this for the logs

// If the current time is after 5 in the afternoon, add another day
if (calculator.isAfter(startTime, "17:00:00")) {
days++;
}

// Putting in some detailed logs
gs.info("MI_SLA_DEBUG - Effective StartDateTime: " + startTime);
gs.info("MI_SLA_DEBUG - Start time after 5 PM?: " + calculator.isAfter(startTime, "17:00:00"));
gs.info("MI_SLA_DEBUG - Days we figured out: " + days);

// Calculate when it's due
calculator.calcRelativeDueDate(startTime, days, "17:00:00");

// You can log after this too if you wanna see the date it figured out, though it might not be right here.
// gs.info("MI_SLA_DEBUG - Rough breach time (double-check the SLA): " + calculator.calculatedBreachTime); // Heads up: Not totally sure if calculatedBreachTime is available here.

Turn the SLA back on, make a test ticket, and then go look at the system logs (System Logs > System Log > All) and search for "MI_SLA_DEBUG". See if that effective StartDateTime is Monday at 8 AM and if "Days we figured out" is 1. That'll tell you if your if logic is okay and the problem's more likely with that calcRelativeDueDate call.

[reginabautista]

Hi Ivan, thanks so much for the detailed reply. Let me try this and get back to you 🙂 

Regina