http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3697 Colin Campbell <colin.campbell@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |colin.campbell@ptfs- | |europe.com Priority|P5 |PATCH-Sent --- Comment #1 from Colin Campbell <colin.campbell@ptfs-europe.com> 2009-10-09 14:35:26 --- Patch submitted due_date field was not being set in the ILS/Item object so the field was not generated -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3697 --- Comment #3 from frederic@tamil.fr 2009-12-01 06:16:15 ---

*** Bug 3815 has been marked as a duplicate of this bug. ***

Colin patch and mine return different date formats. Colin patch: http://lists.koha.org/pipermail/koha-patches/2009-October/004720.html => 2009-12-15 for example Mine: http://lists.koha.org/pipermail/koha-patches/2009-November/004892.html => an epoch I think SIP/MsgType.pm is awaiting an epoch not a formatted date. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3697 --- Comment #5 from frederic@tamil.fr 2009-12-01 10:12:25 ---

I think that MsgType.pm is handling the date format for those date fields completely wrong. In sub handle_item_information around line 1126 it uses the timestamp format which looks like "20091201 100633". This is normally the transaction date format used at the beginning of most SIP2 messages. Fields like due_date, recall_date or hold_pickup_date are usually in the YYYY-MM-DD format.

'are usuallly in the YYYY-MM-DD format' doesn't mean the same thing as MUST BE. What about an hourly loan? It seems that now MsgType.pm expect a epoch formatted date and then it transforms it in timestamp format which is specified in Sip/Constants.pm file. In my opinion, the ILS layer should return what the SIP layer expects. So ILS/Items.pm should be modified.

if (($i = $item->due_date) != 0) { - $resp .= add_field(FID_DUE_DATE, Sip::timestamp($i)); + $resp .= add_field(FID_DUE_DATE, $i); } if (($i = $item->recall_date) != 0) { - $resp .= add_field(FID_RECALL_DATE, Sip::timestamp($i)); + $resp .= add_field(FID_RECALL_DATE, $i); } if (($i = $item->hold_pickup_date) != 0) { - $resp .= add_field(FID_HOLD_PICKUP_DATE, Sip::timestamp($i)); + $resp .= add_field(FID_HOLD_PICKUP_DATE, $i);

'recall_date' and 'hold_pickup_date' seem not to be returned at all... -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3697 --- Comment #7 from frederic@tamil.fr 2009-12-01 11:48:25 ---

The SIP2 standard says that recall date and hold pickup date should be in timestamp format. Due date it says may be returned in 'any format the ACS wishes'. There is a logic in using a consistent format with the other date fields.

Frederic you're using DateTime in this one place to convert the date, would it not be good to consistently handle dates across the sip modules, possibly holding them as DateTime objects? Also DateTime will need adding to the equired modules for Koha.

Joe Atzberger explains that Koha SIP2 ILS abstraction layer is more virtual than real, for now, but that it would be desirable to maintain it and even improve it in order to manage a path for the future to/from a reconciliation with Evergreen SIP Server. Correct me, Joe, if I misunderstood you. In this perspective, I agree with you that we could decide that all dates managed by Sip modules could be with advantage a DateTime object. Of great interest elsewhere in Koha also... The difficulty is to change that without breaking something somewhere. Test suit is not so usable. Or I confess I don't know how to use it. And we lack a Self Check emulator to validated such modification. We all do testing with different devices and not very consistently... -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.