Opened 17 years ago
Closed 13 years ago
#1593 closed defect (fixed)
The drop downs for old billing date are in American mm/dd/yyyy format.
Reported by: | anonymous | Owned by: | Russ Tyndall |
---|---|---|---|
Priority: | normal | Component: | TimingAndEstimationPlugin |
Severity: | normal | Keywords: | date format |
Cc: | stevemccusker@…, Erik Andersson | Trac Release: | 0.10 |
Description
The dates in the rest of Trac (0.10.4) in my Australian setup appear in dd/mm/yyyy format. The billing reports allow the user to enter dates in dd/mm/yyyy format but the results are wrong.
Attachments (0)
Change History (9)
comment:1 Changed 17 years ago by
Cc: | stevemccusker@… added; anonymous removed |
---|
comment:2 Changed 17 years ago by
comment:3 follow-up: 4 Changed 17 years ago by
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?
comment:4 Changed 17 years ago by
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.
comment:5 Changed 17 years ago by
Cc: | Erik Andersson added |
---|
comment:6 follow-up: 8 Changed 17 years ago by
Failing the ability to regionalise, can you implement an internationally universal and unambiguous format for input and lists?
eg: YYYY/MM/DD
comment:8 Changed 17 years ago by
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.
comment:9 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Really there are two problems here.
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.