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: koha-bugs@lists.koha-community.org Reporter: minhpq@tinhvan.com QA Contact: testopia@bugs.koha-community.org CC: lisette@bywatersolutions.com, pedro.amorim@openfifth.co.uk, tomascohen@gmail.com 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.