When I say "time", I mean either time of day or counting times (like for a stopwatch or time used to complete work on an issue).

I've just posted a patch in the forums that supports dates in custom fields, its only the first pass so it might not be 100% at this time, but it might be suitable.

Edit: Can't get the URL to work, look in the Customizations forum on http://forums.mantisbt.org/ for the tread titled "Date Custom Fields patch"

The file mantisbt-cvs-date-patch.zip patch I've just attached contains a context diff and complete modified files for the patch mentioned in the note above. Hopefully I've got the diffs right this time.

I tried to install the above patch on a newly installed version 0.19.2 and got the following error message :

Fatal error: Call to undefined function: user_get_all_accessible_subprojects() in /var/www/mantis_blocked/core/filter_api.php on line 123

There is probably a library missing in the patch, could you help me ?

I didn't make it clear that the changes in the patch are against CVS, not the current release and as such wont apply properly to the 0.19.2 version. The function your talking about is a new feature allready in cvs when I was writing my patch and is not in an area of code I modified.

You have two options really, get the cvs head out which contains the date patch already, or attempt to apply the diff in the attached zip to your current install. Just using the complete files included in the zip wont work.

I've just uploaded a second patch (against CVS at time of submission) that will correct some issues and allow you to define the date range that the user can select (with verification).

Patch file is: mantisbt-cvs-date-patch2.zip

There is a .diff and a full copy of each modified file, you should only apply one.

For defining a date range, define the possible values for the custom field as:

<date> | <date>

Where <date> is anything that strtotime can accept (eg 2005-03-07). I've not tried every single possible method of defining a date so if you find any problems let me know.

Also for those using 0.19.2, I'm working on a backport of the patch to that version since I need this feature at work and current cvs is in too much of a flux to use right now. Keep an eye out and I'll try and have it done in a few days.

Ok, the back port went a bit easier than I thought and seems to be working ok. The file you want for 0.19.2 is mantis-0.19.2-date-patch.zip, it contains complete copies of any modified files but no diff. Be carefull when installing this if you have made other modifications to your install of mantis.

Note: I don't gurantee this will work 100%, as with anything you should back up your data before trying this out, it might be an idea to test it somewhere to. That said, if you have problems let me know (via the forums is probably the best bet) and I'll try to help you out.

The two new files fix an issue where an error would be displayed when people without write access to a date custom field tried to update the bug.

mantis-0.19.2-date-patch2.zip - Fix for 0.19.2 with patch1 from above.
mantisbt-cvs-date-patch3.zip - Fix for current CVS head.

The latest version has the date fields and they work great, except that if you try and export the bug/issue list with the custom fields then the dates are exported as unix timestamps, and not a user-friendly "yyyy-mm-dd" format that Excel and other spreadsheet apps can use.

Anyone have ideas on how we can alter the export to allow for user-friendly times? Perhaps I'm looking in the wrong area. Thnx.

Do any of these patches work with 1.0.0rc3?

For stevemagruder: I've just downloaded the 1.0.0rc3 and these patches are already included, there should be no need to attempt to apply them.

For juellez: The timestamp format makes it much easier to search for specific ranges of dates in the database, but yes it does show as raw data in emails (as do all other custom fields, it just happens that most of that is easily readable). It may be possible to crate some sort of filter for emails going out that converts the value to a easily understood string, but I'm not sure what kind of performance hit that would have on the system.

OK, I see a "Date" custom field. Since it's already there and will be in 1.0, why is this a child of the 1.1 release?

This looks like resolved from fome time now...