Proposal: update 2-digit year import to be configurable/rolling
Overview
The handling of 2-digit years during import uses a heuristic that no longer makes sense. For example, "1/1/22" is imported as January 1, 1922 (not 2022). We should implement something that makes more sense.
Current behaviour
Currently the following is hard-coded into CRM/Utils/Date.php within convertToDefaultDate()
.
// simple heuristic to determine what century to use
// 00 - 20 is always 2000 - 2020
// 21 - 99 is always 1921 - 1999
if ($year < 21) {
$year = (strlen($year) == 1) ? $cen . '0' . $year : $cen . $year;
}
elseif ($year < 100) {
$year = $prevCen . $year;
}
This affects the import of Activity dates and presumably other places where a two-digit year input is selected.
Proposed behaviour
-
Civi should translate 2-digit years into 4-digit years based on a rolling cutoff. For example, if the cutoff is the current date plus ten years, any two-digit input that would result in a date more than ten years in the future will be placed in the prior century instead.
-
The cutoff could be configurable: X years in the future.
Comments
I guess configuration would go under civicrm/admin/setting/preferences/date (CRM_Core_BAO_PreferencesDate
).
Optionally, the setting could be overridable within the import wizard itself.