Please report any other irregularities here.
Some users want to have a field that stores a date and a time. It would be different than just a normal plain-text field because it would be stored as a datetime in the database (so that it sorts correctly) and it would be validated upon entry (to make sure that you couldn't enter an invalid date). Everything except the validation is pretty simple. It probably also ought to be formatted in some nice way, possibly by letting users choose a format. (We could add a "format" column to fielddefs, which could also be used as a regular expression for FIELD_TYPE_FREETEXT to validate the input.) I think that should be done in a separate bug, though. For now we should just require people to input the dates in the format that makes sense to their database.
The validation is pretty trivial, see Util::validate_date() and Util::format_time() to redisplay the date in the format you want.
Okay, so YUI doesn't have a time widget, only a date widget. So either we use a different library than YUI or we find an extension. I don't want to write our own time widget, that would be ridiculous. Also, I'm not going to split every date field into two fields, one for date and the other for time, because that would complicate the code needlessly.
Priority: -- → P1
Target Milestone: --- → Bugzilla 3.2
Created attachment 285456 [details] [diff] [review] v1 Okay, here it is. A very basic implementation. I have to say, Bugzilla's architecture is finally so nice that adding this field was an experience that went exactly like it should have. :-)
Assignee: general → mkanat
Status: NEW → ASSIGNED
Attachment #285456 - Flags: review?(LpSolit)
Comment on attachment 285456 [details] [diff] [review] v1 >Index: template/en/default/bug/field.html.tmpl >+ [% CASE constants.FIELD_TYPE_DATETIME %] >+ <input name="[% field.name FILTER html %]" size="20" >+ value="[% value FILTER html %]"> Nit: I would love to see "(YYYY-MM-DD HH:mm:ss)" being displayed besides the date fields, so that the user has a chance to know which format to use. Else you have to wait to get both date and time errors to discover them. r=LpSolit with or without my nit fixed.
Attachment #285456 - Flags: review?(LpSolit) → review+
I figure we can deal with formatting comments in bug 397102.
Checking in Bugzilla/Bug.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v <-- Bug.pm new revision: 1.212; previous revision: 1.211 done Checking in Bugzilla/Constants.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Constants.pm,v <-- Constants.pm new revision: 1.84; previous revision: 1.83 done Checking in Bugzilla/Field.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Field.pm,v <-- Field.pm new revision: 1.29; previous revision: 1.28 done Checking in Bugzilla/Util.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Util.pm,v <-- Util.pm new revision: 1.62; previous revision: 1.61 done Checking in template/en/default/bug/field.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/field.html.tmpl,v <-- field.html.tmpl new revision: 1.12; previous revision: 1.11 done Checking in template/en/default/global/field-descs.none.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/field-descs.none.tmpl,v <-- field-descs.none.tmpl new revision: 1.25; previous revision: 1.24 done Checking in template/en/default/global/user-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v <-- user-error.html.tmpl new revision: 1.235; previous revision: 1.234 done
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Added to the release notes for Bugzilla 3.2 in a patch on bug 432331.
You need to log in before you can comment on or make changes to this bug.