8,849
edits
Changes
no edit summary
Consider how the standard date input fields are broken up into a date, hour, and minute input but the system actually stores all this data as a single field. MySQL (and most other areas for easy sorting) uses the format "YYYY-MM-DD HH:MM:SS". By using the Date validation on a custom field, uniform date formatting is stored in the system regardless of how each individual user specifies the way they wish to view dates.
2) '''Numbers''': Numbers always need to be entered accurately. Consider how you would store currency data. When you use the Numeric validation and Currency [[Number Format|formatting]] on a custom field, the system actually stores the number value to the full number of decimals and without a [[:Category:Currency|currency]] symbol (i.e. "12.948576"). However, when the system displays this field, it is rounded to two decimals and with a currency symbol (i.e. "$12.95").
3) '''In General''': It's important to have a specific format for any standard data. Take for example, the Canadian postal code which one could enter as "M5V 2H1" or "M5V2H1" (among other variants using lower/upper case letters). The best practice for this example would be to enforce that the user always enters one specific format with upper case letters. This can be done using the validation configuration of a custom field.
[[Category:Chin’s Musings]] [[Category:Custom Fields]]