0004264: CSV export feature should export both date and time - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0004264	mantisbt	feature	public	2004-08-04 12:15	2009-08-02 00:04

Reporter	jvh	Assigned To
Priority	normal	Severity	tweak	Reproducibility	always
Status	acknowledged	Resolution	open
Product Version	0.19.0a2

Summary	0004264: CSV export feature should export both date and time
Description	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 -resolution 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.
Tags	No tags attached.

jvh 2004-08-04 13:02 reporter ~0006636	so i guess i'm asking to have 'long_date_format' as default.

jvh 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.

thraxisp 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.

jvh 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

bala_arun 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).

ohnobinki 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?