The drop downs for old billing date are in American mm/dd/yyyy format.

Really there are two problems here.

1. Dates are stored in the database as a time stamp and as a string. The string is being stored and interpreted in American format.
2. Javascript, when it reads in the date from the textbox,
   • calls new Date( {value from textbox/dropdown list} )
   • once we have a javascript date object, we run Math.round(date.getTime()/1000) - (60 * date.getTimezoneOffset()); to retrieve the unix epoch value of the time.

All of this is to say, that while I can add some configurable date format for storage ( 1), I dont know anything about how to fix (2) as that is something to do with the way the browsers javascript engine interprets dates.

I can still do(1) if necessary, but without (2) it will still break / give you invalid times, because it always uses javascript to build the links to the reports.

If the dates are stored as a timestamp why can't you use the same functions as report.py uses to display the dates in the local format? Or is that what you meant by" add some configurable date format for storage"?

I don't understand the Javascript problem (among many things I don't understand). Can't you pass the date strings back from the Javascript into the python code that executes the reports and do a locale sensitive conversion to dates there?

Replying to anonymous:

If the dates are stored as a timestamp why can't you use the same functions as report.py uses to display the dates in the local format?

I don't execute any python code against the /reports handler. So while I might be able to patch trac to do this, there is no way to do this with the plugin in its current state.

I don't understand the Javascript problem (among many things I don't understand). Can't you pass the date strings back from the Javascript into the python code that executes the reports and do a locale sensitive conversion to dates there?

The short answer is "not to the best of my knowledge". It might be possible to pass the date as a string and use the sql to correctly translate that into a different format. Not really sure about this though, but it might be something to play with. As you have access to the reports, you should be able to diddle them to see if you can figure out what sorts of things passed in the query, and what sorts of sql statements to execute to make that conversion happen correctly.

Unfortunately, I am highly skeptical that there is a cross database way to do this.

Failing the ability to regionalise, can you implement an internationally universal and unambiguous format for input and lists?

eg: YYYY/MM/DD

see also http://trac.edgewall.org/ticket/1690

Replying to anonymous:

Failing the ability to regionalise, can you implement an internationally universal and unambiguous format for input and lists? eg: YYYY/MM/DD

Sorry, I missed this comment and like this solution. I will attempt to make this happen next time I work on this. Sorry for the delay.