Handling daylight saving changes in JIRA Service Management

Many people look forward to the clocks changing to get an extra hour in bed. Here at Adaptavist, it made us wonder what happens to our SLA metrics. Let's look at handling daylight saving changes in JIRA Service Management (formerly known as Jira Service Desk).

JIRA Service Management (JSM) uses the system clock to decide which time is used in its SLA metric calculations. Experience tells us that organisations usually use an imprecise term such as 'office hours' or '9-5' in their service contracts. The upshot of this is that, over the course of the year, we have two different sets of times against which to calculate SLA metrics Summer and Winter.

The table below shows that our Winter timetable is straightforward and just uses the server time of 09:00 - 17:00. However, in Summer, we need to use the server time of 08:00 - 16:00. Ideally, JSM would understand it is Daylight Saving Time (DST). However, it doesn't so we need a workaround.

Implementing a workaround for DST

To accommodate DST, we can build a partial solution (see below) with the following steps.

Firstly, define our Summer and Winter SLA calendars in JSD.

Then take advantage of a scripted field by using ScriptRunner for JIRA. The scripted field calculates whether the issue was raised in the Summer or Winter period. In our example, we have used the name timezone.

import java.sql.Timestamp

// Map of timezones - name and start/end dates in list. Note that timezone names 
// are trimmed to the first 3 letters - key values must be unique
def timezones = ["GMT 1" : ["2018-10-28 01:00:00", "2019-03-31 01:00:00"],
                 "BST 1" : ["2019-03-31 01:00:00", "2019-10-27 01:00:00"],
                 "GMT 2" : ["2019-10-27 01:00:00", "2020-03-29 01:00:00"],
                 "BST 2" : ["2020-03-29 01:00:00", "2020-10-25 01:00:00"],
                 "GMT 3" : ["2020-10-25 01:00:00", "2021-03-28 01:00:00"],
                 "BST 3" : ["2021-03-28 01:00:00", "2021-10-31 01:00:00"],
                 "GMT 4" : ["2021-10-31 01:00:00", "2022-03-27 01:00:00"],
                 "BST 4" : ["2022-03-27 01:00:00", "2022-10-30 01:00:00"],
                 "GMT 5" : ["2022-10-30 01:00:00", "2023-03-26 01:00:00"],
                 "BST 5" : ["2023-03-26 01:00:00", "2023-10-29 01:00:00"],
                 "GMT 6" : ["2023-10-29 01:00:00", "2024-03-31 01:00:00"],
                 "BST 6" : ["2024-03-31 01:00:00", "2024-10-27 01:00:00"],
                 "GMT 7" : ["2024-10-27 01:00:00", "2025-03-30 01:00:00"],
                 "BST 7" : ["2025-03-30 01:00:00", "2025-10-26 01:00:00"],
                 "GMT 8" : ["2025-10-26 01:00:00", "2026-03-29 01:00:00"],
                 "Update script": ["2026-03-29 01:00:00", "2099-12-31 23:59:59"]
]

Timestamp createDate = issue.created // get the issue create date

def timezone = timezones.keySet().find { key -> // Find period create sits in
   Timestamp startDate = Timestamp.valueOf(timezones.get(key)[0]) 
   Timestamp endDate = Timestamp.valueOf(timezones.get(key)[1])
   createDate.after(startDate) && createDate.before(endDate)
}.substring(0, 3) ?: "Update script" // Message to be returned if no match

return timezone

The third and final step is to update the metric goals to use the correct calendar.

Additional criteria checking

You will probably have noticed that we now have two copies of each goal with the additional criteria checking the timezone. The same durations are set for the goal but the calendar is adjusted according to the identified timezone.

Testing the workaround

Now you have a workaround in place, you can test it by checking the tickets raised in the different time periods. You may already have tickets that can be used for this calculation. Alternatively, you can create a test project and import a set of carefully crafted details via the CSV import.

Changes for other timezones

You could update the script above for your timezone replacing GMT and BST with the appropriate 3-letter acronyms. Change the JQL for the SLA goals to match your three letter timezones.

Leave a comment below if you found this workaround useful, we'd love to hear from you.

Notes:

This solution is only a partial solution for the problem of handling timezone changes and is all driven by the time at which the ticket is first created. Any ticket that is handled over the change period may still have inconsistencies on the SLA but this will be fewer than being wrong for a whole time period.

We used https://www.timeanddate.com/time/change/uk/london?year=2016 for the times of clock changes.