Please fix this because it is confusing the team.

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.

I agree with all previous comments. This is an eye sore and causes confusion. Please fix.

I've also been frustrated by this issue. We are a US-based team.

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.

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).

Agree we would like this fixed – with some users in countries that expect dd/mm and other users in countries that expect mm/dd it is difficult to know whether 06/03 on a report is referring to March 6 or June 3. And since we are using On Demand, we cannot change this ourselves.