Bug 22805 - Koha::DateUtils does not support dates with three digit years
Summary: Koha::DateUtils does not support dates with three digit years
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-29 16:00 UTC by Barton Chittenden
Modified: 2023-09-23 17:09 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Barton Chittenden 2019-04-29 16:00:06 UTC
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.
Comment 1 Jonathan Druart 2019-04-29 21:52:35 UTC
Do you have a specific use case? :)

Koha::DateUtils considers that years are formed by 4 digits, 986 is not correctly parsed.
Comment 2 Barton Chittenden 2019-04-30 01:51:05 UTC
(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.
Comment 3 Jonathan Druart 2019-04-30 17:35:37 UTC
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).
Comment 4 Barton Chittenden 2019-05-03 21:47:37 UTC
(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.
Comment 5 Jonathan Druart 2019-05-04 13:40:27 UTC
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.
Comment 6 Nick Clemens 2021-03-17 11:53:20 UTC
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
Comment 7 Katrin Fischer 2023-09-23 17:09:32 UTC
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.