issueFunction expression, and daylight savings time

In a JIRA filter, when using issueFunction in expression to calculate the minutes between two dates, the result is off by 60 minutes if the dates span a Daylight Savings Time switch (2 minutes might be calculated as 62 minutes or as -58 minutes).

Is there a workaround for this, or a way to have the query account for that? I've been able to address it with a calculated field, but I also need to be able to do this in a query directly (e.g., show me all issues where (custom date 1) is more than 30 minutes after (custom date 2), if there's a DST split in between.

Here's my scripted field, if it's useful (populates a calculated field called "Duration"):

def start = getCustomFieldValue("Incident Start Date")
def end = getCustomFieldValue("Incident End Date")
if (start && end) {
   def minutesToAdjust = Math.abs(start.getTimezoneOffset()) - Math.abs(end.getTimezoneOffset())
   return new Double((end.getTime() - start.getTime())/1000/60 + minutesToAdjust)
}
else {
 return null
}

and, if those dates cross a DST boundary, here's a query that returns results that it shouldn't (just as an example... I actually need to use a similar query in a situation where I don't have a scripted custom field):

issueFunction in expression("project = ABC", "(IncidentEndDate - IncidentStartDate) != (Duration * 1000 * 60)")

3 answers

0 vote

Just to help me understand, is this massively significant? Are you querying on durations that are so short they are affected by a lost or gained hour? I don't see a solution to this from the JQL side other than the code taking into account DST. But this should be solvable with a script field? You seem to be saying that is not a solution, but I'm not sure why.

Hi Jamie - This is fairly significant for us. We're using this project to track service disruptions (and manage the return-to-service workflow), so minutes count. The queries related to these fields are meant to be authoritative for informing KPIs and SLAs. The challenge with using a scripted field is that it needs to be predefined. With this particular use case, I could define (and have defined) a scripted field that accounts for this. However, we have a lot of date fields that could potentially be compared to each other, and so creating scripted fields for every possible permutation is impractical. Also, for clarification, the issueFunction query I listed above doesn't actually work - because "Duration" is in this case a Scripted Field, and Scripted Fields cannot be used inside of expression (returning the error "not a Number or Date custom field"), I can't do the compare there either. Short form is that I need users without any admin rights to be able to do these queries comparing dates, without assuming that there's an underlying field... which will also allow us to mostly work around the other issue, where we can't use calculated Scripted Fields inside of issueFunction expression.

0 vote

Thanks for that explanation, that's very clear. That you can't use expression with script fields is: https://jamieechlin.atlassian.net/browse/GRV-695, and I hope to focus on JQL functions within the next 6 weeks. https://jamieechlin.atlassian.net/browse/GRV-713 for the DST issue.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,322 views 14 20
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot