View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009088 | mantisbt | time tracking | public | 2008-04-19 04:18 | 2014-06-11 14:51 |
| Reporter | vboctor | Assigned To | grangeway | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | ||
| Product Version | 1.2.0a1 | ||||
| Summary | 0009088: After upgrade all issues are assigned 1970-01-01 and some are considered overdue | ||||
| Description | Checkout the issues in this bug tracker. It seems that the code that checks whether the time is null or not doesn't work. | ||||
| Tags | due_date | ||||
|
I've noticed that newly created issues don't have a problem. Hence, it seems that the problem is in the upgrade code where it sets the due_date to a non-null value. |
|
|
Since I dont have access to database itself, could you tell me whats the value of due_date field in "old" issues?? Overdue status is connected wit it too. I'll try to simulate this situation and fix it asap. |
|
|
Patch that fix the issue posted in bug 0008942. |
|
|
Changed target version from 1.2.0a2 to 1.2.0 since the due date feature is now disabled by default. |
|
|
Treating this the same as the other issue relating to due dates that I can't reproduce on the latest code: Marking this as resolved - no change required - appears to be fixed in newer releases of MantisBT. I'm struggling to reproduce this, and the date submitted timestamp for this issue of 2008, is before we converted due dates (or well, dates in general) to integer values due to issues with using DateTime fields in the DB with things like this. If anyone is still reading this, and can come up with a more modern / current bug report on the functionality, that can be easily reproduced, we can look at getting the new issue(s) fixed properly. Victor: in terms of the upgrade issues in this, we had Timezone issues with the initial code, converted due dates (dates) to integer fields in April 2009 [a year after this bug report], and during the conversion, we set any value <100,000 i.e. 1.2 days or something to a value of 1 which would tidy up the original timezone issues. If there's still something that neesd fixing here, as per above, lets new issue it with a clear bug to fix |
|