Symptom: Crash on save when in memberentry.pl for a particular patron. Inspecting the plack error logs, I saw The given date (02/26/986) does not match the date format (us) at /usr/share/koha/lib/Koha/DateUtils.pm line 168. To replicate: Edit a patron. Set the first digit in the year of the patron's birthday to 0, e.g for a 'MM/DD/YYYY' formatted date, this would be '02/26/0986' Click save. This causes an Internal Server Error.
Do you have a specific use case? :) Koha::DateUtils considers that years are formed by 4 digits, 986 is not correctly parsed.
(In reply to Jonathan Druart from comment #1) > Do you have a specific use case? :) > > Koha::DateUtils considers that years are formed by 4 digits, 986 is not > correctly parsed. Jonathan, If you enter the date date of birth as '02/26/0986' *in memberentry.pl* it gets saved as '0986-02-26' in the database. Somewhere in the process of loading that into Koha::DateUtils, the leading 0 is lost, which causes the crash -- '0986' is obviously a typo of '1986', and that's causing the crash.
Here it is not saved, the crash appears at Koha::Patron::get_age('Koha::Patron=HASH(0x55dfa6af0400)') called at /home/vagrant/kohaclone/members/memberentry.pl line 338 before the patron is stored (on line 434).
(In reply to Jonathan Druart from comment #3) > Here it is not saved, the crash appears at > Koha::Patron::get_age('Koha::Patron=HASH(0x55dfa6af0400)') called at > /home/vagrant/kohaclone/members/memberentry.pl line 338 > > before the patron is stored (on line 434). Ok, let's fix that then. I've changed the bug title accordingly.
If it is not saved it means that comment 1 is valid and, so, what is the use case? :) If it's an typo to handle I'd prefer to fix it client-side (force the date plugin to get a date > 1000, maybe 1900?) and not hack Koha::DateUtils.
While initially filed as affecting patrons over 1000 years old, this bug has implications in other places - In serials (try setting first issue publication date to 01-01-999) - Items can set an acquisition date of 01-01-999 These may be edge cases, but I don't see why we should not support three digit years
It looks like this might be resolved with flatpickr. It doesn't let you enter a 3 digit year, it always resets to the current year then. And if you save 0999, the year still displays nicely when the patron is edited.