http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10824
David Cook <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #20791|0 |1 is obsolete| | --- Comment #3 from David Cook <[email protected]> --- Created attachment 21613 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21613&action=edit Bug 10824 - OAI-PMH repository/server not handling time in "from" argument This patch remotes the DATE() function from around timestamp, and adds a sub that strips the UTC designators "T" and "Z" from incoming "from" and "until" arguments in OAI-PMH requests so that they're more compliant with MySQL (and probably other databases as well). TEST PLAN: 0) Note down a selection of timestamps from your biblio table 1) Enable your OAI-PMH server through the global system preferences Web services tab. 2) Craft and submit a similar request to the following in your browser: KOHAINSTANCE/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=oai_dc& from=2013-09-02T13:44:33Z&until=2013-09-05T13:44:33Z Change the exact dates to accord with your timestamps, but keep the YYYY-MM-DDTHH:MM:SSZ format. 3) Note the unexpected behaviour. A "from" argument with the timestamp 2013-09-02T13:44:33Z will show records from 2013-09-03 but not records from 2013-09-02 even though the timestamp in the database will say "2013-09-02 13:44:33". 4) APPLY THE PATCH 5) Resubmit the links you tried above 6) Note that the applicable records now appear! -- Developer Note: We could've not stripped the UTC designators and used DATE() around the parameters in the SQL queries, but that would have lost the whole purpose of using times in the "from" arguments, since they would've been generalized to just the dates. I think this is probably the best solution. Admittedly, creating "form_arg" and "until_arg" hashrefs in the ResumptionToken object might not be ideal, but I preferred that to copying the _strip_UTC_designator subroutine into two other objects. Perhaps this sub could go somewhere else and be imported into those other two objects but this seemed to be the most sensible decision. I'm open to other opinions though. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
