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
return OpenILS::SIP->format_date($date) if $date;
to
return OpenILS::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)
>>> 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=)
>>> 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]
