Summary: | Koha::DateUtils does not support dates with three digit years | ||
---|---|---|---|
Product: | Koha | Reporter: | Barton Chittenden <barton> |
Component: | Patrons | Assignee: | Bugs List <koha-bugs> |
Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | gmcharlt, jonathan.druart, kyle.m.hall, nick |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11220 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27937 |
||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: |
Description
Barton Chittenden
2019-04-29 16:00:06 UTC
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. |