Target date recalcultes when time zone is change

[xaxa_1]

Hello, experts

Consider the following:

I have time zone A (say GMT) and time zone B (say GMT+7) and an incident ticket that was opened in timezone B at 20/10/11 14:00. Let's assume that work hours start at 09:00 and end at 18:00 Mon-Fri, and the incident has 8 work hours for resolution. So SLA target date is 21/10/11 13:00 in time zone B.

Now at 21/10/11 12:00 B-time it gets reassigned to a group in time zone A. So at this moment there is 1 work hour left for resolution. 21/10/11 12:00 B-time correspond to 21/10/11 05:00 A-time. I'd expect SLA target date to become 21/10/11 10:00 A-time. But it turns out that SM always calculates target date from the very beginning, from open.time in $L.file. In time zone A open time is 20/10/11 07:00, and 8 hours adds up to new SLA target date = 20/10/11 17:00. But now it is 21/10/11 05:00 already! So the incident gets breach instantly!

If you turn this logic upside down you can see that when you reassign from time zone A to time zone B you get additional work hours for resolution. Ofcourse, customers complain only when they lose hours....

How can I change this behaviour? Specifically, I want to keep "how many work hours were left" and transfer them to a new time zone.

Many thanks for ideas

[RobertWil]

In SLO record you can define which timezone you're going to use.
If I were a client I would insist on using my tz.

Your idea with switching groups and counting how many work hours were left, can be implemented by recalculating time left at every reassignment.

But when you implement such thing you will be able to postpone deadline just reassigning incident (back and forth) between groups in different time zones.

[xaxa_1]

OK, thank you for the reply, but I don't quite follow you....

In all SLOs we have tz.type = "customer" and customer.field in slamodulecontrol for probsummary is "folder".

"folder" is associated with assignment group's time zone. It is automatically changed after every reassignment.

How can I implement my idea by recalculating time left at every reassignment? I thought I'd need to create a specific field in probsummary (say slo.left) and put it in all SLOs... so basically there will be only one SLO. Then in im.save process I would have to add calculations of how many work hours were left before reassignment, add them to reassignment time to get new SLA target date and then substract open time from new SLA target date to get new slo.left. I'd have to use calendar.calc.interval and calendar.calc.date RAD applications there.... do you mean the same thing? Why do you think I can postpone a deadline by reassigning in this case?

[RobertWil]

---

@xaxa_1 wrote:

How can I implement my idea by recalculating time left at every reassignment? I thought I'd need to create a specific field in probsummary (say slo.left) and put it in all SLOs... so basically there will be only one SLO. Then in im.save process I would have to add calculations of how many work hours were left before reassignment, add them to reassignment time to get new SLA target date and then substract open time from new SLA target date to get new slo.left. I'd have to use calendar.calc.interval and calendar.calc.date RAD applications there.... do you mean the same thing? 

---

Thats exactly what I meant.

As to the deadline, take assumptions from your first email.

8wh for resolution

group A: tz:GMT 9-18

group B: tz:GMT+7 9-18 = GMT 2-11

GMT from now on

register incident to group A at 10 -> deadline=day0 at 18:00

at day0 11:00 reassign to B -> 7wh left, deadline=day1 9:00

at day0 19:00 reassign to A -> 7wh left, deadline=day1 16:00

at day1 11:00 reassign to B -> 5wh left, deadline=day2 7:00

at day1 19:00 reasign to A -> 5wh left, deadline=day2 14:00

at day2 11:00 reassign to B -> 3wh left, deadline=day3 5:00

and so on...

If i were your customer I wouldn't agree to that easily.

[xaxa_1]

Hello again, Robert!

This request is from my customers, so they've agreed 🙂

Right now, there are many - many SLOs with different conditions, for different changes of problem.status, it seems to be a nightmare to move all of this functionality from default mechanism to this new one, where I have to recalculate slo.left myself.

So I thought.... if I create a new field, say "new.open.time", in probsummary, and replace open.time with new.open.time in slamodulecontrol. Then I will reproduce this same "recalculation mechanism" but to recalculate new.open.time instead of slo.left. It will be some "effective openning time". In this case, it seems I can leave all SLOs and conditions untouched and they will work as designed.

To illustrate what I mean, in the example from the first post, I have open.time in $L.file = '20/10/11 07:00' (time zone A) and I will set new.open.time in $L.file = '20/10/11 11:00:00' (time zone A).

What do you think of that?