Comment 2 for bug 994796

Hmm. The sickness seems to go deep. I added some logging code in OpenILS/WWW/EGCatLoader/Util.pm around line 570:

###
    $ro_object_subs->{parse_datetime} = sub {
        my $date = shift;

        $logger->warn("My date is $date");
        $date = DateTime::Format::ISO8601->new->parse_datetime(cleanse_ISO8601($date));
###

At the added logger line with a due date of "0212-10-08", the output is: "[WARN:26756:Util.pm:186:] My date is 212-10-08T23:59:27-0517". I confirmed that the date in the database itself is '0212-10-08 23:59:59-05:17:32'. So the leading 0's are stripped from the date before the TPAC code even tries to transform it, suggesting that CStoreEditor itself is doing the stripping.

See user/dbs/bad_dates_are_okay in working for a fix for this problem at the TPAC layer. I think this should be applied to master through rel_2_2 as soon as it gets some confirmation that it fixes the reported problem. As it is defensive code, it won't hurt to keep this in place in the future.

We could also consider trying to address this case in cleanse_iso8601() in OpenSRF, although I'm a bit less comfortable munging dates in a more generic situation.

I think we must investigate why CStoreEditor is returning the dates with the leading 0s stripped off and fix that problem as well, as that will also resolve some problems in the staff client (e.g. displaying checked out items for a patron returns an empty string in this situation currently) and probably other functional areas as well.

Once again, that's http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/bad_dates_are_okay for the TPAC-level fix.