* the dates should be printed in human-readable format, not in timestamp * The patron debarment can now have a date (new feature of BibLibre circ improvements). We have to deal with this date on the SIP messages
Created attachment 3464 [details] [review] Clean patch Patch was already sent to the mailing list but some merge problems remained. So, this is a clean patch that format dates to be readable by human beings. Also sent to mailing list.
Created attachment 3554 [details] [review] Another patch
The date patch reformats some dates in the item information response which have their formats specified in the sip standard. Also while due date does not have a specified format some units assume all dates will be formatted the same (i.e. the sip format), I once did the same change for the same purpose only to find a sites self check machines stop functionning. On 3M machines date formatting can be configured on the self check unit itself.
Reading Colin's comment it sounds like Failed QA? Do we need a different solution for the problem? And does this patch rely on the 'fines in days' feature?
*** Bug 6042 has been marked as a duplicate of this bug. ***
Alex, Assigning this bug to you, as you've written the 6042 patch. Please read comments from both patchs, investigate & argue. In the meantime, marking this patch "failed QA" as the 6042 one (hint : maybe there's a difference between french 3M self-checkouts & english ones...)
Hi there! I went through the whole SIP2.0 manual from 3M and I got 15 instances of date-use using the SIP::timestamp and 3 usages with no definition (optional) of the timeformat (see down). All undefined usages are using the AH-field. <SNIP> 2.00 Item Information Response due date AH variable-length optional field. 2.00 Renew Response due date AH variable-length required field Checkout Response due date AH variable-length required field 2.00 Hold Response 2.00 expiration date BW 18-char, fixed-length optional field: YYYYMMDDZZZZHHMMSS </SNAP> I think one can strongly infer from the documentation that using the established timeformat (the SIP-format) is supposed to be used. The SIP-device vendor anyway should format the date to be displayed per configuration.
(In reply to Olli-Antti Kivilahti from comment #7) > I think one can strongly infer from the documentation that using the > established timeformat (the SIP-format) is supposed to be used. > The SIP-device vendor anyway should format the date to be displayed per > configuration. Took a look at 3M's SIP 3.0 document and it specifies all these to use sip formatted dates.
Reading the last 2 comments it looks like we should not change the date formatting (assuming we are using sip formatted dates right now). Should we close this bug?