-
Bug
-
Resolution: Fixed
-
Medium
NOTE: This bug report is for JIRA Software Cloud. Using JIRA Software Server? See the corresponding bug report.
The date format in the greenhopper burndown report does not follow the rules set in the jira application.
- is related to
-
-
- Closed
-
-
-
- Closed
-
[JSWCLOUD-6145] greenhopper board report date format does not follow jira date format
George Lee
added a comment - Please fix this because it is confusing the team. 
JT
added a comment - The fact that the Sprint's use a Date/Time format causes many issue for us. We have teams spread across multiple time zones, the Date will often change depending on where you are. Example: The Close Date of the Sprint is scheduled for 2/26/14. Our JIRA instance is set to a system default time is (GMT-05:00) New York. If I close a Sprint at 2/26/14 at 10:00PM MST, it will show the Sprint closing on 2/27/14 due to the time zone difference. These dates should not have a time component.
JT
added a comment - The fact that the Sprint's use a Date/Time format causes many issue for us. We have teams spread across multiple time zones, the Date will often change depending on where you are. Example: The Close Date of the Sprint is scheduled for 2/26/14. Our JIRA instance is set to a system default time is (GMT-05:00) New York. If I close a Sprint at 2/26/14 at 10:00PM MST, it will show the Sprint closing on 2/27/14 due to the time zone difference. These dates should not have a time component. 
Jeff Brinkerhoff
added a comment - I agree with all previous comments. This is an eye sore and causes confusion. Please fix.
Jeff Brinkerhoff
added a comment - I agree with all previous comments. This is an eye sore and causes confusion. Please fix. This is also true for the date-picker in Agile sprint configuration
I would agree with this being more than a minor bug. I do a double take every time i look at the reports because.
Please fix. I'm using 6.3.0.2 and it's especially unsettling in the Version reports.
Connie Landry
added a comment - OnDemand administrators need to be able to have the authorization to modify this date format - right now, just Atlassian Sys Admins have authorization, and even they cannot fix it. This is something customers Administrator should be able to customize for themselves. We too utilize mm/dd - very confusing for us to look at the Burndown chart to see it listed as dd/mm (United States user).
Connie Landry
added a comment - OnDemand administrators need to be able to have the authorization to modify this date format - right now, just Atlassian Sys Admins have authorization, and even they cannot fix it. This is something customers Administrator should be able to customize for themselves. We too utilize mm/dd - very confusing for us to look at the Burndown chart to see it listed as dd/mm (United States user). I think this is a bit more than a minor bug. It confuses people and then makes them think less of the product because it seems like an easy thing to fix. I'm really surprised it made it past testing of the reports originally.
For download version- on the version tab for the project if you try to release you must change the date using the picker in order to release the version. We use MM/DD/YYYY date format, the Greehopper plugin (and version date picker) defaults to DD/MMM/YYYY. So any date picked in a version must be repicked in Greenhopper.
See ...secure/admin/ViewLookAndFeel.jspa for defaults (may be admin changeable but I'm locked out if it is).
Fix this. I've had nothing but simple problems with complicated solutionssince ive started using Jira...