Thank you for pointing that out!
So it has been much quicker and I can now confirm that in both cases
investigated (i.e., a usual hold and a hold in transit) the response
after CM contains the correct 18 characters representing both day and
time in the format prescribed by the SIP standard!
I have now added it as a bug:
https://bugs.launchpad.net/evergreen/+bug/2132079
As to the locker, it is a product sold by a Czech company KP-SYS and it
just seems to expect the standard (albeit a really old one) to be
followed (more details, if these are interesting for a wider audience,
can be provided by Eva Cerninakova).
So it is great that now the CM field format adheres to the standard and
we can continue in our testing efforts (obviously we will need to work
with more requests than just with those which focus on providing
information about the item :-)!
Thank you once again for helping us sort it out!
Linda
On 11/20/25 15:27, Josh Stompro wrote:
You don't need to recompile for this type of change to a perl module,
you can edit the file and restart things since perl isn't a compiled
programming language.
I usually quickly find the file in question with a command like
# *find ./ /usr/ | fgrep 'SIP/Item.pm'*
/usr/local/share/perl/5.36.0/OpenILS/SIP/Item.pm
and then edit it, you need to edit it as root since it is in its
installed library location.
*sudo vim /usr/local/share/perl/5.36.0/OpenILS/SIP/Item.pm*
You can use vim or whatever editor you are familiar with. If you are
not familiar with vim it has a learning curve.
You can also edit it in your local evergreen install directory and
then copy it over using sudo so you can use something like visual
studio. The evergreen install process doesn't change SIP/Item.pm,
just moves it around.
I'm not quite sure what specifically needs to be restarted after that
change, so I would just restart everything, Evergreen and the
SIPserver just to be sure.
Have you started a bug on this yet? It would be good to
know specifics about the lockers that require this change.
Josh
On Thu, Nov 20, 2025 at 12:02 AM Linda Jansová
<[email protected]> wrote:
Hi Josh,
Thank you, we will give it a try! (Probably over the weekend as we
usually work with the tarballs rather than directly with the code,
so it will take us longer to actually make the change in a test
environment and compile Evergreen.)
As to the other dates, I cannot say I am a SIP2 expert ;-) but
judging from
https://developers.exlibrisgroup.com/wp-content/uploads/2020/01/3M-Standard-Interchange-Protocol-Version-2.00.pdf
(the
Internet Archive currently reports a 503 error when trying to
reach the archived version of the SIP standard) I guess that
perhaps not all of the fields you have mentioned are actually used
by the SIP server. Hold pickup date certainly is but I cannot see
(in this SIP standard version) patron date of birth for example (I
believe that for practical reasons it is rather unlikely for the
date of birth to be recorded as date and time of birth as in most
cases it would go into unnecessary and often not even officially
recorded detail; otherwise bogus time data would have to be
included)...
Making the format configurable without breaking existing
integrations sounds very good to me! Thank you for suggesting it!
Linda
On 11/19/25 23:22, Josh Stompro wrote:
Reading through the standard, every date is specified as being in
YYYYMMDDZZZZHHMMSS format.
https://web.archive.org/web/20110707063609/http://mws9.3m.com/mws/mediawebserver.dyn?6666660Zjcf6lVs6EVs66S0LeCOrrrrQ-
Patron birth date was added in an extension to the standard,
which doesn't seem to specify the format? But I don't know why it
wouldn't follow the same format as the others.
Changing all the dates to align with the SIP date format
might break existing integrations, so it probably cannot just be
fixed without it being configurable. I see that the new
sip2mediator changed the name of the 'use_sip_date_format" option
to 'due_date_use_sip_date_format' to be more specific about what
the setting does.
So maybe adopt that change of name for the SIPServer code while
still supporting the old name, and add a
'hold_pickup_date_use_sip_date_format' option to change the hold
pickup date to use the SIP format?
Josh
On Wed, Nov 19, 2025 at 3:31 PM Josh Stompro
<[email protected]> wrote:
I think this is a bug, or maybe something that also needs to
have a config flag.
The format_date function only appears to use the
"use_sip_date_format" setting if the date is identified as a
'due' date. Every other date seems to be formatted with
$date= sprintf("%04d%02d%02d", $year, $mon, $day);
So the time info is not used.
https://gitlab.com/LARL/evergreen-larl/-/blob/main/Open-ILS/src/perlmods/lib/OpenILS/SIP.pm#L142
It looks like these dates get formatted with that function.
* Checkout Due Date - special handling
* Item Due Date - special handling
* Hold Pickup Date
* Patron DOB - slight bit of special handling to set to
local timezone
* Patron Expire Date
Only the due dates are formatted in the SIP format. So does
the standard say that all those other dates should be
formatted in the long form SIP format? I haven't looked to
see if that is the case.
For a quick test if you change this line
https://gitlab.com/LARL/evergreen-larl/-/blob/main/Open-ILS/src/perlmods/lib/OpenILS/SIP/Item.pm#L415
|returnOpenILS::SIP->format_date($date) if$date;|
|to|
||returnOpenILS::SIP->format_date($date, ||'due') if$date;
It will use the special handling for the due date to format
the hold_pickup_date to the sip format, as long as
'use_sip_date_format' is also enabled.
Josh
On Wed, Nov 19, 2025 at 2:24 PM Linda Jansová
<[email protected]> wrote:
Dear Josh and Lorne,
I am sending a snippet from the log file which among
other lines includes this one:
"Nov 19 19:32:38 SPOK24 opensrf_sip[230584]: OILS:
formatted date [type=]: 20251107"
The full snippet after logging in is copied below:
Nov 19 19:32:37 SPOK24 opensrf_sip[230584]:
read_SIP_packet, INPUT MSG: '1720251101
084453AOjabokkn|AB424480012374'
Nov 19 19:32:37 SPOK24 opensrf_sip[230584]:
read_SIP_packet, trimmed 2 character(s) (after chomps).
Nov 19 19:32:37 SPOK24 opensrf_sip[230584]: INPUT MSG:
'1720251101 084453AOjabokkn|AB424480012374'
Nov 19 19:32:37 SPOK24 opensrf_sip[230584]:
Sip::MsgType::new('Sip::MsgType', '1720251101', '17'):
msgtag '0'
Nov 19 19:32:37 SPOK24 opensrf_sip[230584]:
Sip::MsgType::_initialize('Item Information', '20251101
084453AO...')
Nov 19 19:32:37 SPOK24 opensrf_sip[230584]:
Sip::MsgType::_initialize('Item Information', '20251101
084453AOjabokkn|AB424480012374', 'A18', '18', ...
Nov 19 19:32:37 SPOK24 opensrf_sip[230584]: OILS: Loading
item 424480012374...
Nov 19 19:32:38 SPOK24 opensrf_sip[230584]: OILS:
Item('424480012374'): found with title 'Malá filosofie
člověka : a Slovník filosofických pojmů'
Nov 19 19:32:38 SPOK24 opensrf_sip[230584]: OILS: media
type = 001
Nov 19 19:32:38 SPOK24 opensrf_sip[230584]: OILS: No open
circ found for copy
Nov 19 19:32:38 SPOK24 opensrf_sip[230584]: OILS:
formatted date [type=]: 20251107
Nov 19 19:32:38 SPOK24 opensrf_sip[230584]: OUTPUT MSG:
'1808020120251119 193238AB424480012374|AJMalá filosofie
člověka : a Slovník filosofických
pojmů|CK001|AQJAB-KN|APJAB-KN|BHCZK|BV0.00|BGJAB-KN|CF1|CM202>
Nov 19 19:32:38 SPOK24 opensrf_sip[230584]: SIP
processing duration 0.176 : 1720251101
084453AOjabokkn|AB424480012374
Nov 19 19:33:38 SPOK24 opensrf_sip[164414]: Child process
230584 exited with status 0 - signal was 14
We have also tried to experiment a little bit with holds
in transit; in this case the date was in the same format
as without the "in transit" status, e.g.:
CM20251127
A column entitled shelf_expire_time (hopefully the right
one) in the hold_requests table (under the action schema)
includes values like:
2025-11-07 10:24:23.087+01
2025-11-11 10:48:27+01
2025-11-11 10:53:02+01
But this is just how these values are reported back when
one uses an SQL query; sometimes (as I understand it), it
may not equal to what is actually stored in the database,
e.g., the value may be reported in a different time zone
<https://www.geeksforgeeks.org/postgresql/postgresql-timestamp-data-type/>.
Of course we have restarted not only the SIP server but
also our Evergreen installation, so in that case I
believe the "use_sip_date_format" setting should have
been picked up correctly. Just to make sure it looks
correct we have restarted all services again; the log
shows the following lines:
Nov 19 21:15:20 SPOK24 opensrf_sip[231144]:
2025/11/19-21:15:19 SIPServer (type Net::Server::PreFork)
starting! pid(231144)
Nov 19 21:15:20 SPOK24 opensrf_sip[231144]: Resolved
[0]:8080 to [0.0.0.0]:8080, IPv4
Nov 19 21:15:20 SPOK24 opensrf_sip[231144]: Resolved
[*]:6001 to [::]:6001, IPv6
Nov 19 21:15:20 SPOK24 opensrf_sip[231144]: Not including
resolved host [0.0.0.0] IPv4 because it will be handled
by [::] IPv6
Nov 19 21:15:20 SPOK24 opensrf_sip[231144]: Resolved
[*]:8023 to [::]:8023, IPv6
Nov 19 21:15:20 SPOK24 opensrf_sip[231144]: Not including
resolved host [0.0.0.0] IPv4 because it will be handled
by [::] IPv6
Nov 19 21:15:20 SPOK24 opensrf_sip[231144]: Binding to
TCP port 8080 on host 0.0.0.0 with IPv4
Nov 19 21:15:20 SPOK24 opensrf_sip[231144]: Binding to
TCP port 6001 on host :: with IPv6
Nov 19 21:15:20 SPOK24 opensrf_sip[231144]: Binding to
TCP port 8023 on host :: with IPv6
Nov 19 21:15:20 SPOK24 opensrf_sip[231144]: Group Not
Defined. Defaulting to EGID '1001 1001'
Nov 19 21:15:20 SPOK24 opensrf_sip[231144]: User Not
Defined. Defaulting to EUID '1001'
We do not use any custom code and have not applied any
filter.
We have not tested SIP2 Mediator
<https://docs.evergreen-ils.org/docs/latest/admin/sip_server.html#_sip2_mediator>
yet;
can it actually coexist with the original SIP2 server?
Thank you for helping us figure it out!
Linda
on behalf of the Czech Evergreen community
On 11/19/25 16:23, Linda Jansová wrote:
Thank you very much, Josh!
Now it is a bit clearer to me why we haven't seen
anything in the SIP2 settings within the staff client as
these would probably be the ones used by SIP2 Mediator
rather than by the SIP2 server mentioned in the official
documentation
<https://docs.evergreen-ils.org/docs/latest/admin/sip_server.html#_installing_the_sip_server>
(which
we followed when trying to make it all work; it is great
that new sections about SIP2 Mediator and about filters
have now been added
<https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fb4959fec943baf9ef1057354b0e5e17634139ec>
:-)!).
We will try to test it and then report back.
Linda
On 11/19/25 15:47, Josh Stompro wrote:
I think the original sip2 server uses the evergreen
code under Open-ILS/src/perlmods/lib/OpenILS/SIP/
In this spot there is logic that approximates the
hold_pickup_date if the item is still in transit.
https://gitlab.com/LARL/evergreen-larl/-/blob/main/Open-ILS/src/perlmods/lib/OpenILS/SIP/Item.pm#L391
So you could test with an item in transit to fill a
hold and an item on the hold shelf and see if the
output is any different.
Ah, ok so /OpenILS/Application/SIP2 is part of the
newer Sip2 server - Sip2Mediator -
https://github.com/berick/SIP2Mediator
https://bugs.launchpad.net/evergreen/+bug/1901930
So you could also give that a try and see if the
problem still exists there? I haven't run that one yet
so I don't know what would be involved.
Here is the perl module where the hold_pickup_date is
pulled for the newer Sip2 Server.
https://gitlab.com/LARL/evergreen-larl/-/blob/main/Open-ILS/src/perlmods/lib/OpenILS/Application/SIP2/Item.pm#L106
It doesn't look like the new Sip2 server tries to
approximate the hold pickup date for items in transit
like the original code does.
Josh
On Wed, Nov 19, 2025 at 12:54 AM Linda Jansová
<[email protected]> wrote:
Thank you very much, Josh!
Linda
On 11/18/25 22:49, Josh Stompro wrote:
Hello Linda,
I think the intention was for the hold pickup date
to be in SIP format going by.
https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l194
188
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l188>
Returns the location of C<$patron_id> in the hold queue for the
189
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l189>
item, with '1' indicating the next person to receive the item.
A
190
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l190>
return status of '0' indicates that C<$patron_id> does not have
a
191
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l191>
hold on the item.
192
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l192>
193
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l193>
=item C<$date = $item-E<gt>recall_date>
194
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l194>
=item C<$date = $item-E<gt>hold_pickup_date>
195
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l195>
196
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l196>
These functions all return the corresponding date as a standard
197
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l197>
SIP-format timestamp:
198
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l198>
199
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l199>
YYYYMMDDZZZZHHMMSS
200
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l200>
201
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l201>
Where the C<'Z'> characters indicate spaces.
The response gets built here
https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=Sip/MsgType.pm;hb=HEAD#l1212
I'm not really seeing anything that would make me
think the date is getting changed. So the date
might be getting truncated before it gets to the
SIPserver code. I'll look some more when I have a
chance.
Josh
On Sat, Nov 1, 2025 at 4:49 AM Linda Jansová via
Evergreen-general
<[email protected]> wrote:
Hi,
We are in the process of setting up a pickup
locker which we hope will work together with
Evergreen (currently 3.13.1), using the SIP
server.
Currently, if we ask for item information
(request 17 in the SIP protocol parlance), we
get the 18 response but it contains the CM
field value (which represents hold pickup
date) in the YYYYMMDD format which seems to be
incorrect (not accurate enough or, in other
words, too short).
A sample request (sent after successfully
logging in via telnet and so there is a
manually added date at the beginning of the
string):
1720251101 084453AOjabokkn|AB424480023074|
Response to this request which we have
received (with the CM field highlighted in bold):
1808020120251101
092707AB424480023074|AJTropika diskursu :
kulturně kritické
eseje|CK001|AQJAB-KN|APJAB-KN|BHCZK|BV0.00|BGJAB-KN|CF1|*CM20251107*|CTJAB-KN|CSFL-1.4/W|
So CM’s value is 20251107, not the long date
we would wish to receive.
The guidelines entitled "How to Set Up a SIP2
Server for Self-Check Systems" (used for Aleph
but containing also the generic SIP
information; available from
https://files.mtstatic.com/site_11811/57183/3?Expires=1761987196&Signature=BUhN1BmluFzxM4NH~0LnIQRvkqtOS8p5Z1drTKv6X66zWrkazeGiJ4Hhx8h8evPbXRn-bPDQZqBqYMrJXhla-epAH4o02MMYdbk2r0N0s7-dpywSLws-XfUBKihwCARK0vf3~C9UX7~-AMgAUmZsWNZl6tcaVoi3JvbCuVhy43M_&Key-Pair-Id=APKAJ5Y6AV4GI7A555NA
<https://files.mtstatic.com/site_11811/57183/3?Expires=1761987196&Signature=BUhN1BmluFzxM4NH~0LnIQRvkqtOS8p5Z1drTKv6X66zWrkazeGiJ4Hhx8h8evPbXRn-bPDQZqBqYMrJXhla-epAH4o02MMYdbk2r0N0s7-dpywSLws-XfUBKihwCARK0vf3~C9UX7~-AMgAUmZsWNZl6tcaVoi3JvbCuVhy43M_&Key-Pair-Id=APKAJ5Y6AV4GI7A555NA>)
give the following specification for the CM
date format:
"18-char, fixed-length field: YYYYMMDDZZZZHHMMSS."
In the Evergreen SIP config file
(https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=SIPconfig.xml.example.evergreen;hb=335ba9848c620c7c5e35fd05ebb9fcaf188b316f)
we have enabled (uncommented) the following
option:
<option name="use_sip_date_format" value="true"/>
Given its description ("By default, most dates
use the SIP date format. Some, like
circulation due dates, use the ISO8601 date
format instead. If this setting is set to
true, all dates will use the SIP date
format."), it looks pretty much like something
that might help the date format to appear in
the correct format.
However, after enabling the option and
restarting Evergreen, the date is still
delivered in the YYYYMMDD format.
Evergreen documentation
(https://docs.evergreen-ils.org/docs/latest/admin/sip_server_communication.html#sip_17-18_item_information)
mentions the CM field but the sample responses
do not contain this field and its value
(obviously, this piece of information is not
always applicable, so its absence in the
examples is understandable).
The Item.pod file
(https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=335ba9848c620c7c5e35fd05ebb9fcaf188b316f)
mentions:
"=item C<$date = $item-E<gt>recall_date>
=item C<$date = $item-E<gt>hold_pickup_date>
These functions all return the corresponding
date as a standard
SIP-format timestamp:
YYYYMMDDZZZZHHMMSS
Where the C<'Z'> characters indicate spaces."
This file was last changed in 2016, so even if
we are on 3.13.1 and not on the latest
version, it is already there.
We have noticed some recent changes to the SIP
server (e.g., relating to filters:
https://git.evergreen-ils.org/?p=SIPServer.git;a=commitdiff;h=335ba9848c620c7c5e35fd05ebb9fcaf188b316f)
but we are not sure if they might be (in one
way or another) relevant in our case (?).
The Launchpad bugs (found using the simplest
sip query:
https://bugs.launchpad.net/evergreen/+bugs?field.searchtext=sip&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=DEFERRED&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<https://bugs.launchpad.net/evergreen/+bugs?field.searchtext=sip&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=DEFERRED&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=>)
do not seem to mention the date issue.
We have also tried to have a look elsewhere
(e.g., at
https://pines.georgialibraries.org/docs/doku.php?id=circ:holds:book_lockers)
but as the GAPINES documentation focuses on
procedures which are to be performed by
librarians rather than on setting up the SIP
server, it does not provide any clues to the
CM date format issue.
Any ideas where else to look (which particular
setting to change etc.) to make the date
appear in the right (i.e., long) format in the
SIP server response?
Thank you very much for providing any hints!
Best,
Linda
on behalf of the Czech Evergreen team :-)
_______________________________________________
Evergreen-general mailing list --
[email protected]
To unsubscribe send an email to
[email protected]
_______________________________________________
Evergreen-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
