For a known limitation documented in PRB1270618/KB0693401, the "setDateNumericValue" method can be used on GlideDateTime/GlideDuration fields such that, if you set the same value twice into a field using this method, the field will be marked as unchanged.
This can affect retroactive pause time calculations when attaching a Task SLA, because "setDateNumericValue" is used to set the SLA duration fields. During the calculation of retroactive pause time, it is possible that the business time left and/or business elapsed time fields have not been updated between different historical updates.
This then results in these fields being marked as unchanged when inserted into the database, and so the Task SLA has no business pause value impacting the calculation of other durations on the record.
Steps to Reproduce
1. Modify the timezone of of the User record to be in a timezone where the current time is before 8am or after 5pm.
2. Create a new Incident with the caller and Impact/Urgency set to "2 - Medium" (Priority will be "3 - Medium").
3. Check that a "Priority 3 resolution (1 day)" Task SLA is attached to the new Incident, that the SLA shows Business time left is one day, and the business elapsed time is empty.
4. Update the Incident to have a state of "On hold", and an on hold reason of "Awaiting Caller".
5. Check that the Task SLA is now paused.
6. Update the Incident to have Impact of "1 - High" (this will change the Priority field to "2 - High").
7. Notice the original "Priority 3 resolution (1 day)" will be cancelled and a new "Priority 2 resolution (8 hour)" Task SLA will be attached. Even if the business elapsed time is still correctly shown as empty, the business time left is blank rather than showing the expected 8 hours.
This issue is fixed in Madrid. There is no workaround applicable. Please review the Fixed In section to determine the latest available patch your instance can be upgraded to.
Related Problem: PRB1305315