https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43701
Bug ID: 43701
Summary: ISO 18626 timestamps are not valid xs:dateTime, which
stops conformant partners parsing
Initiative type: ---
Sponsorship ---
status:
Product: Koha
Version: Main
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P5 - low
Component: ILL
Assignee: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
CC: [email protected],
[email protected], [email protected]
Target Milestone: ---
Split out of bug 43674 comment #6 at Pedro Amorim's request.
Koha/ILL/ISO18626/Request.pm emits timestamps with a space separator and no
timezone:
<timestamp>2026-09-30 10:23:41</timestamp>
<lastChange>2026-09-30 16:38:51</lastChange>
Neither is a valid xs:dateTime, which requires the T separator. ISO 18626 also
expects
UTC, so the missing timezone leaves the value ambiguous between agencies in
different
zones.
Impact
Of the defects found while testing Koha against a third-party ISO 18626
implementation,
this is the one that actually stops the exchange. Tested with the same message
content
in three variants:
- correct schema order, correct timestamps -> parses; XSD validation passes
- scrambled element order -> parses; XSD validation fails
- timestamp with a space -> parser THROWS; XSD validation
fails
So unlike the element ordering in bug 43694, which a non-validating parser
tolerates,
this one is fatal: our deserialiser raises an exception and the message is
lost. We work
around it by rewriting timestamps before parsing, which we would rather not do.
Note the same code gets it right elsewhere. In the plugin,
_send_requesting_agency_message already uses
strftime( '%Y-%m-%dT%H:%M:%SZ', gmtime )
while create_request uses
strftime( "%Y-%m-%d %H:%M:%S", localtime )
so the two senders disagree with each other as well as with the schema.
Reported against
the plugin at https://github.com/openfifth/koha-ill-iso18626/issues/7 with a
patch in
https://github.com/openfifth/koha-ill-iso18626/pull/5; core has the same
problem.
Suggested fix
Use strftime('%Y-%m-%dT%H:%M:%SZ', gmtime) wherever an ISO 18626 timestamp is
produced,
or a shared helper so the two senders cannot drift apart again. Worth checking
every
element typed xs:dateTime, not just timestamp and lastChange.
Found on Koha 26.05.02. Related: bug 43674 (envelope, patched), bug 43694
(element
order), bug 43695 (agency identifiers).
Happy to test a patch against the same setup.
--
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
