Please reconsider...

Hi Customers,

We want to set expectations for the improvements that will come in the next 12-18 months, and this suggestion is not something we are considering in that timeframe.
Thank you for watching, voting, and commenting on this issue.

Eduardo | Atlassian Support Team

It’s been since March 23, 2010, last update January 4, 2016, and now it’s September 27, 2024—it’s time to move forward with this!

It's an essential feature in project management and basic analysis ..

dmeyer do we have any update on this? It has been close to a decade since you commented on this issue. Are there any plans to implement date comparisons in JQL?

Is there any workaround here?

This would still great to have

We need to compare two date field in JQL

is there any update on this issue yet - it's ridiculous that something that should be simple and an automatic function in project management is not yet available. We have migrated to cloud and were using the issue function feature on server, but now we are unable to report on tasks completed past due because the cloud has no capability.

We have build an app able to compare dates.

Vision SQL for Jira Cloud

Disclaimer: not for the exact requirement as this is SQL  and not JQL strictly. However, it supports JQL too to search for issues and then compare dates on the results with SQL

As this issue is older than 10 years with no resolution yet, it might help some of you.

Definately something we expect as the core functionnality of JQL in Jira cloud.....

As a client..that seem something basic that we should not need to buy a 3rd-party

One more vote from our Org as well. 

It shouldn't depend on the number of votes. It's an essential feature in project management.

I still wonder, Is it that difficult to implement???

Hello,

as far as I can see this issue was reported in 2010.

It has 554 votes since then.

I would like to know how many votes it should have approximately to be effectively considered for implementation.

I feel that it is useless to keep voting, without knowing what weight those votes have in the universe of issues pending analysis.

Thank you very much.

One more vote from our organization!

Can Jira Cloud include date comparison by default without any addons like scriptrunner.

Like, it should be easily possible to compare:

duedate < resolutiondate

22 years and counting while it gathers interest, with 541 votes to get it implemented!
How many VOTES are needed before it is considered for implementation?

It's still gathering interest.

Apparently not a much interesting feature since 2010...

It's kind of insane this isn't available.  I have been operating under the assumption it would work because it seems like such a basic idea.  Shocked this hasn't been done yet.

Strong support for this requirement from my side - just failed comparing duedate < resolutiondate and dateComapre not working in the Cloud.

+1, all the date fields should use the same standard format and should be comparable

+1 and for timespent fields also

IMHO, this should be core functionality, but what is more concerning is that there has been no update from Atlassian in 5 years.

Nearly 500 votes, and it still gathering interest (dust) since 2016

Come on, Atlassian, you are better than this. I agree with all the previous comments: This should be core functionality; your userbase shouldn't need to advocate for this.  The Atlassian Product Manager, you should be screaming about this to your decision-makers.

It would be helpful if we could have an explanation as to why this can't/won't be done. For example, has someone taken a look and realized it will take 5 person years of effort to implement?

Is Dave Meyer's position above still the prevailing thinking?  I certainly hope not.

A query engine that doesn't support date comparison in the predicate.  Seriously?!?!

This is very poor for a product that touts itself with a sales pitch like " With all project information in place, reports can be generated to track progress, productivity, and ensure nothing slips." yet it can't query issues that compare one date field against another.  https://www.atlassian.com/software/jira/guides/use-cases/what-is-jira-used-for#jira-for-project-management-teams

C'mon Atlassian, you need to be better than this.  This should be core functionality; your userbase shouldn't need to have to advocate for this.  Dave, as a Product Manager, you should be screaming about this to your decision makers.

+1

I need the ability to track when issues are resolved after their due dates, ideally without having to pay for an additional plugin.

This is (once again  ) some functionality that I would have believed existed in Jira...

Our case: we want to create a queue in Jira Service Management that shows:
"all issues that were updated recently after they got resolved".

We want this queue in order to notice when the customer has put a comment on a resolved issue.
We had the template automation rule activated "re-open issue when reporter comments", but this would also reopen issues when they just say "Thanks!".
=> not needed to re-open in that case.
+ everybody gets spammed with way too many notification mails about these status changes (solved - reopened - solved) and new comments....

The reporting capabilities of Jira are very limited without having this basic functionality which is present in every other reporting/tracking system. The ability to compare dates is essential to produce insightful reports. 

+1

I thought it was a basic query until I found this issue. It looks like I'm wrong. 

Almost a decade after there's still no solution. 

This was created and responded to in 2016, surely there is advancements within three years that will allow a JQL query to compare two dates without using a plug in such as scriptrunner?

Utterly disappointing. A little explanation on why this cannot be done would have helped maybe. Doesn't seem really technically complicated...

Happy belated anniversary Atlassian team!

6 days ago was the 7th anniversary of this feature request, still not considered for implementation, still upvoted by the community...

Blow your candles, let's make a wish ^_

I am disappointed this feature is not planned for the near future.  The plugins suggested for workaround are for the cloud version, not server so none of these work for us.

Please consider this in the next batch of enhancements.

I realize Atlassian has rejected this, but I'm going to add another vote. JIRA should support comparing any two similar field type fields for a match, and for dates or number fields, it should include options for any Operator. To limit Operators to fixed values instead of other field values seems narrowly focused.

Since some time ago there is another plugin able to compare dates: SQL for JIRA is based on the popular H2 database and allows to:
1. Convert JIRA JQL queries into standard SQL
2. Operate on JIRA data with the H2 functions
3. Convert the SQL (2) into a new JQL with the built-in sql function:

issue in sql("<your SQL returning issue keys here>")

Comparing two date fields is a critical need for me. Seems pretty basic.

+1 for comparing Number Fields, as well.

Hi everyone,

Thanks for voting and commenting on this issue. Your feedback is key to helping us understand how you use JIRA so we can continue improving your experience. We have reviewed this issue over the last few days; unfortunately we don't have any plans to support this in JIRA for the foreseeable future.

Please remember that jira.atlassian.com is one of many inputs for the JIRA roadmap. You can learn more about our process here.

I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.

Regards,
Dave Meyer
dmeyer@atlassian.com
Product Manager, JIRA Platform

Unfortunately, no workaround at the moment lglalonde

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

Hi,

Since comparing dates using JQL is not implemented yet, is there a workaround available? Thanks!

Very surprised this isn't implemented yet. The reporting that can be done in Confluence from Jira in a Cloud install is pretty disappointing. What is the point of all this integration if in the end we'll have to write our own solution using the API and whatnot?

+1 for having this natively in JIRA. This is a must-have for tracking and reporting, especially since we need to compare resolution date against other date fields to see whether we are consistently meeting our SLAs.

I understand the context and don't get me wrong, I am a big fan of JIRA and tell many people about how great it is. However, when a feature like this which is as important as this is left out, it causes concerns. I have been asked several times why JIRA doesn't allow for dates to be compared, why we can't have different priorities for different projects/issue types, why we can't have numbers in project keys, why it doesn't have more add-ons which have been time-proven on the non-cloud instances, etc., and my response will just have to be, "Because they don't want to add that feature and are working on other issues that people don't necessarily want." Every issue I have followed has resulted in, "Sorry we are not putting this on the roadmap" despite the number of comments/votes, with the exception of the messes which were made when time tracking always sent out notifications and the forced naming structure of account names. Thankfully, those were fixed.

I also understand your resource constraints, but for a long time, I think that JIRA is under-priced for what it does, and I think companies wouldn't mind paying a little more if they could get features like this one. If you don't keep up with the others who are doing more development, you will ultimately lose your customers.

Thanks.

Hi stodegaard, it's probably little consolation, but I went into more detail about our reasoning on JRA-6218, if you want to have a look at my comment there. I understand why this is frustrating to you, but hopefully the extra context will be valuable

Thank you for replying, Shawn. I'm 100% with you on the Excel workaround. It didn't sound super viable, just an example of pretty much the only workaround I could think of. Definitely not a very repeatable task...

Benjamin, yes you could use that as a workaround, but that doesn't really qualify as "easily show". Easily show would be that you could create a filter and put it on a dashboard, instead of the laborious task of running a filter (which can't compare dates) and export to Excel, then add a column which does an =if(date1>date2,"X",""), then filtering on that column to pull out just the issues you want. To make it so you don't have to search through the possibly 100+ fields the report will have, you should save your filter with only the columns you want and do a Current Fields export.

<rant>
Not to mention the annoying way that export templates include the annoying extra 3 lines at the top (the logo, the filter link, and the "Displaying <xx> issues at <time>) and the useless line at the bottom "Generated by...." which always need to be deleted if you want to do pivot tables, but you cannot change these templates to make those lines go away.
</rant>

It just seems ridiculous that adding this functionality would be discarded in favor of some of the other things which are going in. Would this be really that hard to implement? It would have great benefit to any user of JIRA. It seems like every good suggestion is dismissed as not being good enough for the roadmap.

Since there doesn't seem to be a fix in sight, I'm curious if anyone has any workarounds. Export to Excel and do comparisons?
May have made a tiny promise that we could easily show which tasks were completed after their due date because I assumed it'd be a simple JQL query. Alas, I'm in search of an alternative way to report on this...

Chris, that isn't what this issue is about. It is about the ability (or lack thereof) to compare dates in a filter.

In the workflow transition, a validator is able to compare dates.
This is the exact functionality required for this ticket!

The ability to report on users who change due dates as well would be so beneficial to catch bad planners or slackers.
I'm copying the due date on issue creation to a read-only field for comparison but even this is impossible!

200+ votes and not on backlog created 5+ years ago?

Our organization's biggest pain point with service desk is the inability to automate (for Cloud instances) status changes based off customer responses on tickets. A simple filter to address this would be to filter for tickets where the updatedDate is greater than the resolvedDate, however this is currently incompatible. Seems like a great extension of JQL that should be added.

Agree with Joanne's 2014 comment: Something like (resolved - due) = 2d would be very useful.

Additionally, since i assume this might take 10 years to schedule and actually get this implement, Has anyone managed to create reports using nested mysql queries?

Hi Oswaldo,

This is unbelievable because someone logged an issue on 23/Mar/10 already ?!

Pieter

Hi all,

Just a quick update on status on this issue.

At the moment, this is not on the short-term backlog of any team so it is unlikely we will be able to work on this in the next 12 months.

Having said that, this is still an issue we would like to address, we will update its status as soon as more information is available on it.

Thanks for all your feedback.

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

Similarly, I would like to search for issues where the Time Remaining is greater than the Original Time.

This would be extremely useful. Any idea of when it might make it into a release?

I am trying to differentiate "working on known bugs" vs. "creating more bugs". Please consider having this feature to make life a lot easier, thanks.

Please, let us either have this functionality - or allow ScriptRunner on Jira OnDemand

I would like to see a response as well.