View Issue Details

IDProjectCategoryView StatusLast Update
0004264mantisbtfeaturepublic2009-08-02 00:04
Reporterjvh Assigned To 
Status acknowledgedResolutionopen 
Product Version0.19.0a2 
Summary0004264: CSV export feature should export both date and time

Currently CSV export only exports dates and therefore only tracks resolution times, etc. accurately up to 24 hours. It would assist greatly in reporting to also export the time for:
-date created
-last update

also, this request may be duplicated somewhere else but the CSV export feature should also export any custom fields that have been created on a project basis.

TagsNo tags attached.


child of 0004181 closed Features in Mantis 1.1 release 




2004-08-04 13:02

reporter   ~0006636

so i guess i'm asking to have 'long_date_format' as default.



2004-08-04 13:19

reporter   ~0006638

also, has there been any thought into keeping a 'resolution date' in the db. when trying to report on how fast an issue was turned around, the best you can do currently is compare date_submitted with last_updated. an issue may have been resolved but someone can still re-open the bug and add a bugnote to it, effectively skewing those calculations.



2004-08-04 14:27

reporter   ~0006639

For issues tracked using 0.18, the resolution date is in the history_table. I added this feature to the summary report under 0003710. We might create a csv report with dates (latest) for all of the statuses.



2004-08-05 11:42

reporter   ~0006659

Last edited: 2004-08-09 13:23

Well, going forward, is there going to be more accurate data for issue turn-around? I have read the discussions where some people consider 'CLOSED' to be the final resolution and others, like us, who consider 'RESOLVED' to be the final resolution. It seems more accurate to log both the date/time an issue is set to either somewhere in the db. Perhaps storing this information in the history table is enough, but I think its worth considering to have a field like 'last updated' in the mantis_bug_table that logs resolution time. Resolution time really shouldn't be something you have to dig to get in the bug's history table and should definately be a standard element in the csv export. We really would like custom fields to appear in the cvs export as well since many of the custom fields have to do with revenue assesments, etc....Your thoughts?

edited on: 08-05-04 16:35

edited on: 08-09-04 13:23



2007-06-05 11:28

reporter   ~0014677

Last edited: 2007-06-05 11:33

Here are my thoughts: Resolution and response times should be calculated for each ticket by the system and stored in the db and not in history. Response time: the time interval between the ticket creation and the first change of 'Status'. Resolution Time: The time interval between the end of response time and the last time the ticket reaches a pre-defined status ('Resolved' or 'Closed' based on the configuration).



2009-08-02 00:04

reporter   ~0022646

IMO, CSV export's time/date output should be just as configurable as the main interface's output. I can, however, see how software which uses the CSV output feature might want to be able to depend on a standard output format.

If the time resolution is not to be configurable, may the highest resolution of time be printed for fields such as ``Updated''? i.e., may the complate_date_format be used?

Issue History

Date Modified Username Field Change
2004-08-04 12:15 jvh New Issue
2004-08-04 13:02 jvh Note Added: 0006636
2004-08-04 13:19 jvh Note Added: 0006638
2004-08-04 14:27 thraxisp Note Added: 0006639
2004-08-05 11:42 jvh Note Added: 0006659
2004-08-05 16:35 jvh Note Edited: 0006659
2004-08-09 13:23 jvh Note Edited: 0006659
2004-08-24 12:29 thraxisp Status new => acknowledged
2004-08-24 12:29 thraxisp Relationship added child of 0004181
2007-06-05 11:28 bala_arun Note Added: 0014677
2007-06-05 11:33 bala_arun Note Edited: 0014677
2009-08-02 00:04 ohnobinki Note Added: 0022646