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]
