Jira listener plugin timezone problem

Jira Development
, ,
1

I’ve got this jql query that I use to list issues based on certain conditions:

              MutableIssue issue=(MutableIssue) event.getIssue();
             JqlClauseBuilder clauseBuilder = JqlQueryBuilder.newClauseBuilder();
             Query query = clauseBuilder.assigneeUser(issue.getAssignee().getName()).
                and().resolution("unresolved").
                and().sub().
                priority().lt(issue.getPriority().getName()).or().
                priority().eq(issue.getPriority().getName()).and().
                created().gt(issue.getCreated()).endsub().
                buildQuery();

When I log the query.toString(), I see that the issue created date is always 1 hour earlier than the one I see in the issue detail window. I would immediately doubt time zone, but I can’t understand why the application shows 18:46 but the query generated has 17:46 when they run on the same server. I mean, I upload the plugin to the jira application where the issue created date is always 1 hour later (in fact the application shows the correct time) than what issue.getCreated returns inside JQL. Do you have an idea?

1 Like
2

The time printed by the plugin is the time in the server where the application is deployed. And the time shown in the application is the user’s timezone.

This can happen if your server is a Central Time but the user is in East Coast in the US.

Check your timezone setting (Choosing a Time Zone | Jira Software Data Center and Server 6.4 | Atlassian Documentation) and compare it with server time.

2 Likes
3

@jobinkk, I’ve been struggling with this problem for a week now. But haven’t been able to find a solution to it. Both the server and user have the same time zone. It’s AZT +04. What I can’t understand is this: Why do I get the issue itself besides other ones from the above JQL? I clearly say that get me those that either have lower priority or have the same priority but created later than this one. Here’s the generated query:

{assignee = "mikola"} AND {resolution = "unresolved"} AND ( {priority < "High"} OR {priority = "High"} AND {created > "2017-03-27 17:46"} )

So, if this issue was created on “2017-03-27 17:46”, then why does the JQL include this issue in the result?

1 Like
4

Did you misplace the brackets (for the OR condition) ? Shouldn’t it be:

{assignee = "mikola"} AND {resolution = "unresolved"} AND ( {priority < "High"} OR {priority = "High"} ) AND {created > "2017-03-27 17:46"}

1 Like
5

No. That’s not wrong. I need either lower priority ones or the ones that are the same priority and created later than this one. And that does what I need.

6

You mean this?

{assignee = "mikola"} AND {resolution = "unresolved"} AND ( {priority < "High"} OR ({priority = "High"} AND {created > "2017-03-27 17:46"}) )

I added an extra pair of brackets for the AND condition in the last clause.

1 Like
7

In fact, I had added those extra sub/endsub. But as AND operator is evaluated first, they’re redundant. If my memory serves me correctly, the the JQL ignored those extra brackets in the end and didn’t appear in the generated query.

8

Mikola, do you realize that the time zone setting can be defined differently for each user account?

Even if your JIRA has the default timezone X, a user may select timezone Y for himself, and I’d expect that ultimately the timezone of the user account on behalf the JQL is executed is the one that matters.

May worth a check.

9

Ok, I finally solved the problem. As I was suspecting, the problem was caused by the fact that here, in Azerbaijan, we cancelled Day Light Saving in 2016. An the server had no patch for this case. Here are the steps I followed to get correct time zone information.

  1. Downloaded tzdata2017c.tar.gz from offiacial IANA website
  2. Downloaded tzupdater.jar from this Oracle link
  3. Run this little code as a java program
    TimeZone timezone = TimeZone.getDefault();
    System.out.println("DayLight Saving: " + timezone.getDSTSavings());
  1. This returned “DayLight Saving 3600000”. It means I needed to apply the java patch
  2. Calculated the SHA512. Go to the folder where you downloaded the tzdata file and run this command:
    sha512sum tzdata2017c.tar.gz | cut -d’ ’ -f 1 > tzdata2017c.tar.gz.sha512.
  3. Then run the below command
    java -jar tzupdater.jar -v -l file:///<full_path>/tzdata2017c.tar.gz
  4. Rerun the code in step 3. If it says “DayLight Saving: 0” – it means we’ve fixed it.

After this patching I get correct date/time in the server code.

And the problem regarding why the issue itself appeared in the list was because the JQL was omitting the part after minutes. So, although the issue was created on 2017-04-19 15:15:48.31, the JQL included only 2017-04-19 15:15 part.

Getting different due date when invoking getDueDate