Jira due date only allows up to aprx 20 years from current date. for example, if you put 2044 (21 years) it will be reverted back to 1944 when you close and reopen the issue. I want to see whether there's any way to solve this.
Hi Everyone,
I am a new user and pleased to see the amount of response from the community.
In summary does it appear to a genuine bug and how would I go about reporting it to the Jira Software development team?
Hello @joseph.roy
It already has been reported. Refer to the bug JRACLOUD-82550. Just add your comments / votes to that logged bug
As for increasing the range of the date field, refer to the existing Feature Suggestion JSWCLOUD-25791. Vote for it if you agree.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @joseph.roy
I've duplicated that bug:
It seems others have reported it too. Refer to JSWCLOUD-25791 and JRACLOUD-82550.
Personally, I have no need to set Issue Due Dates so far into the future, but if you do, then add your vote for the bug to be resolved.
Cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Sunny Ape , I wonder if the limit is on custom dat field and not the "Due date" field? I'm certainly puzzled by my results given the JAC issues you shared.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Another thought...
how are you setting the date? For my tests I click into date field and type "1/1/2045" rather than trying to use the calendar.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Howdy @Jack Brickey
I have tested:
and get the same results. I haven't tested with a team managed project.
I know that Atlassian do run very slightly different 'flavours' of the cloud platform in different regions and asometimes one region can get a feature / bug that other doesn't, so this might be a regional problem. I'm going add my vote and comments to the open bugs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Jack Brickey
Try changing the date, close the Issue view window, maybe navigate away, then re-open the Issue view and see if it's still the same date.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Sunny Ape , here are my results:
summary:
I can successfully set the duedate to a date well into the future. JQL seems to have some limitations which I plan to investigate with colleagues.
note: I was testing, purely with company managed projects in Jira software.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
With all that said, it would be interesting for you to open a ticket with Atlassian support and have them login to your site and investigate. If you do, so, please report back here. by the way, is the behavior you're experiencing systematic and that you have tested this with other projects and other issues?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok...final testing...enough time spent. Clearly a limitation as suggested by the open JAC issues.
even though I can set the date successfully to beyond 20 years and have it displayed correctly. I don't believe that the date is being recognized internally. The reason I say this is that JQL will not find that date.
Due = 2045-01-01 - no issues returned even though the issue displays the same date.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.