#6229 closed defect (fixed)
Date fields for reports require specific format and do not return errors properly
| Reported by: | Owned by: | Russ Tyndall | |
|---|---|---|---|
| Priority: | normal | Component: | TimingAndEstimationPlugin |
| Severity: | normal | Keywords: | |
| Cc: | Trac Release: | 0.11 |
Description
On the reports page, the text boxes for start and end time require a text string suitable for JavaScript's Date.parse() method:
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Date/parse
The form of which is similar to:
"Mon, 25 Dec 1995 13:30:00 GMT"
It does not accept more useful RFC-compliant date strings. The report page should at least say this, if not offer a reasonable date picker widget.
Perhaps more importantly, the tests for invalid dates don't work as intended in the JavaScript code. I never see the 'alert' statement no matter what I enter. I don't have more detailed information as I'm having difficulty getting any breakpoints to work in the code.
Testing with Trac 0.11, TAEP 0.8.0, FireFox 3.5x.
Attachments (0)
Change History (5)
comment:1 Changed 15 years ago by
comment:2 Changed 15 years ago by
Ah, you're right. That format does work, however the following do not:
2009-11-16 11-16-2009 11/16/09
I'm accustomed to the first being a non-ambiguous, sortable format. Not your fault JavaScript is kind of backwards when it comes to that.
Thanks for the quick response.
comment:3 Changed 15 years ago by
yes, I much prefer yyyy-mm-dd for its iSO8601-ishness, unambiguity and relative saneness.
While I am digging around in there, I might whip up a regex to check for iso date stamps.
Russ
comment:4 Changed 15 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Date entry on the billing/management/time reports screen should be more forgiving.
I have pulled in a javascript date library that seems to do a better job of parsing arbitrary date formats. On my check it seems to support both the current date format and iso8601 type descending precedence dates.
Hope this helps Russ
Hmmm... Dates in the form MM/DD/YYYY work fine as best I can tell. (so you dont have to use the funky format up there). I agree accepting many standard and locale specific formats would be nice, but that is not feasible (at least for me now). I will look into adding a Calendar widget or something.
The date validation code not working is somewhat more troubling. When I get a chance, I will attempt to rectify this.
Sorry for any inconvenience, Russ