The task.sla_due value is miscalculated when the SLA Calendar is defined for a different time zone from the application session time zone.
Steps to Reproduce
Navigate to SLA > Calendars > Create New.
Add calendar spans for a time zone other than the calendar timezone.
For example, set the span 3:30 am - 10 pm for the GMT time zone, but from a PST instance session time zone.
Navigate toreate a new SLA definition on the Incident table.
For more information, see the documentation topic Create an SLA definition.
Define the start and pause conditions, and create escalation intervals for Moderate, High, and Overdue.
Create an incident and update the record conditions in order to trigger the SLA.
Once the SLA start condition is matched, check the SLA due time on the incident record.
Note that the time value is not accurate.
This behaviour is expected and will not be modified in the Express legacy SLA engine. The issue does not occur in the new ITSM Enterprise SLA engine.
Make sure that the session time zone is the same as that of the calendar's time zone, when the spans are created. If the instance default timezone is different from the wanted calendar's timezone, it will need to be switched before creating the SLA calendars.
If a calendar span like 3:30 AM - 10 PM is created for a GMT timezone from a PST instance session timezone (not the timezone set in users profile), this will be converted and saved in the database as 11:30 AM - 6:00 AM (next day) GMT.
To avoid unexpected SLA results, the session time zone has to be same of the wanted calendar timezone, while the time spans are being created.
In the example in the Steps to Reproduce, while creating a GMT calendar, if the session time is set to GMT, the spans are created as expected: 3:30 AM - 10 PM in GMT = 19:30:00 - 13:00:00 PST. All subsequent SLA calculations, even switching to different timezones, will be as expected.
Related Problem: PRB881381