When I use the calendar picker to find tickets created between 9/1/15 and 9/30/15 or when I use the JQL "created >= 2015-09-01 AND created <= 2015-09-30" I get a list of tickets created 9/1 through 9/29 but the tickets created in 9/30 are omitted. Why is this?
This is EXTREMELY frustrating - it is already difficult to create month-based queries, but now we have to assume a +1 days for every between search?
Probably because you omit the time and it defaults to 00:00. Change the end date comparison to "< 2015-10-01" or add " 23:59" after "2015-09-30".
Come on, man - seriously? Try to do a basic search. You get between day X and day Y. Turn that into advanced search and you get the JQL I showed above. Search that includes <= should remember the = as in anything on that day. You have to recognize that this is a major bug.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sorry, didn't pick up on the ' calendar picker' part as I NEVER use basic search myself. Just trying to help a fellow user here, but I agree, when you do a basic search with between dates it makes a lot of sense to include the whole time frame of the 'ending' date.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sorry, this has me in a bit of a cranky mood - I realized that because of this bug many monthly reports I've submitted to upper management are missing issue data. As for Basic search, that's my default. I can craft JQL, but that doesn't mean I want to. I only use JQL when I have to perform a search that goes beyond the capabilities of Basic search, and even then I wind up creating the framework of the search in Basic then switch over. Its a matter of preference. Even so, bear in mind that while most admin (other than myself) may prefer JQL, regular end users may not like it at all.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No problem and no offense taken. Agreed that this should be modified as it is counter-intuitive. I'll even go as far as to send out an internal email to our JIRA users warning about this. Sorry you had to find out the hard way... "Make it a great day and a better tomorrow!" //Sten
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Tip: Not sure if they're in a plugin or standard JIRA, but in Advanced/JQL you can possibly use startOfMonth(-1) and endOfMonth(-1) to get the last/prior month, always.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Sten - earlier today when I discovered this issue I found that solution to my own monthly report issue, and it works well. However, I can guarantee that other users are going to have all sorts of problems setting up their own date range filters. I want to find a way to put a positive spin on this but... if searching by day, in absence of time, that should be interpreted as any time on that day from 00:00 to 23:59.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Just want to add here that we have a suggestion to change this default behavior in https://jira.atlassian.com/browse/JRA-39509. You might be interested in cast a vote and add yourself as a watcher to be aware of any news from our developers.
Cheers!
Teilor
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for providing this link. I have voted for this issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
+1 Thank you Teilor!
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.