[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-21 Thread Lorne Churchill via Evergreen-general 
Hello Linda, thank you for your followup & for bringing this interesting case 
forward. 

Many thanks to Josh as well for pointing thru to the right direction.
___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-20 Thread Linda Jansová via Evergreen-general 

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á 
 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
MMDDHHMMSS format.


https://web.archive.org/web/20110707063609/http://mws9.3m.com/mws/mediawebserver.dyn?660Zjcf6lVs6EVs66S0LeCOQ-


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
 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

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-20 Thread Josh Stompro via Evergreen-general 
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á 
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
> MMDDHHMMSS format.
>
>
> https://web.archive.org/web/20110707063609/http://mws9.3m.com/mws/mediawebserver.dyn?660Zjcf6lVs6EVs66S0LeCOQ-
>
> 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 
> 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
>> 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á 
>> wrote:
>>
>>> Dear Josh and Lorne,
>>>
>>> I am sending a snippet from the log file which amo

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-19 Thread Linda Jansová via Evergreen-general 

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 
MMDDHHMMSS format.


https://web.archive.org/web/20110707063609/http://mws9.3m.com/mws/mediawebserver.dyn?660Zjcf6lVs6EVs66S0LeCOQ- 



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 
 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á
 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'): foun

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-19 Thread Josh Stompro via Evergreen-general 
Reading through the standard, every date is specified as being in
MMDDHHMMSS format.

https://web.archive.org/web/20110707063609/http://mws9.3m.com/mws/mediawebserver.dyn?660Zjcf6lVs6EVs66S0LeCOQ-

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 
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
> 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á 
> 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:
>> '1720251101084453AOjabokkn|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', '20251101084453AO...')
>> 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
>> : 1720251101084453AOjabokkn|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 repo

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-19 Thread Josh Stompro via Evergreen-general 
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á 
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:
> '1720251101084453AOjabokkn|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', '20251101084453AO...')
> 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
> : 1720251101084453AOjabokkn|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
> 
> .
>
> 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]:

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-19 Thread Linda Jansová via Evergreen-general 

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 
.


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 
 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 
 (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 
 
:-)!).


We will try to test it and then report back.

Linda

O

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-19 Thread Linda Jansová via Evergreen-general 

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 
 (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 
 
:-)!).


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á 
 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


Returns the location of C<$patron_id> in the hold queue for the
189


item, with '1' indicating the next person to receive the item.  A
190


return status of '0' indicates that C<$patron_id> does not have a
191


hold on the item.
192



193


=item C<$date = $item-Erecall_date>
194


=item C<$date = $item-Ehold_pickup_date>
195



196


These functions all return the corresponding date as a standard
197


SIP-format timestamp:
198



199


MMDDHHMMSS
200



201


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  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 MMDD format which seems to be incorrect (not
accurate enough or, in other words, too short).

A sample request (sent

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-19 Thread Josh Stompro via Evergreen-general 
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á 
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
> 
> Returns the location of C<$patron_id> in the hold queue for the
> 189
> 
> item, with '1' indicating the next person to receive the item.  A
> 190
> 
> return status of '0' indicates that C<$patron_id> does not have a
> 191
> 
> hold on the item.
> 192
> 
> 193
> 
> =item C<$date = $item-Erecall_date>
> 194
> 
> =item C<$date = $item-Ehold_pickup_date>
> 195
> 
> 196
> 
> These functions all return the corresponding date as a standard
> 197
> 
> SIP-format timestamp:
> 198
> 
> 199
> 
> MMDDHHMMSS
> 200
> 
> 201
> 
> 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 MMDD 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):
>> 1720251101084453AOjabokkn|AB424480023074|
>>
>> Response to this request which we have received (with the CM field
>> highlighted in bold):
>> 1808020120251101092707AB424480023074|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-bPDQZqBqYMr

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-18 Thread Linda Jansová via Evergreen-general 

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 
 
Returns the location of C<$patron_id> in the hold queue for the
189 
 
item, with '1' indicating the next person to receive the item.  A
190 
 
return status of '0' indicates that C<$patron_id> does not have a
191 
 
hold on the item.
192 
 

193 
 
=item C<$date = $item-Erecall_date>
194 
 
=item C<$date = $item-Ehold_pickup_date>
195 
 

196 
 
These functions all return the corresponding date as a standard
197 
 
SIP-format timestamp:
198 
 

199 
 
MMDDHHMMSS
200 
 

201 
 
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 
 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 MMDD
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: MMDDHHMMSS."

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:



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 MMDD format.

Evergreen documentation

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-18 Thread Linda Jansová via Evergreen-general 

Dear Lorne,

Thank you very much for this list of all the additional things to check!

We will look into it and hopefully we will eventually be able to find 
the right spot where the date gets truncated (if it was ever available 
in full of course)!


Best,

Linda

On 11/17/25 20:32, Lorne Churchill via Evergreen-general wrote:

Hello Linda,

In case you have not found a solution yet, here are a few more things to check in 
order of easiest to deeper, to find & fix the root cause:

1. Verify that the SIP server is really reading the “use_sip_date_format” 
setting

Double-check the file path and whether that option is being picked up by the 
SIP server process.

Sometimes after editing SIPconfig.xml, a service restart (or complete 
stop/start) is required; ensure the config change actually took effect.

Monitor the SIP server startup logs for any warnings/errors about invalid 
config or unrecognized option.

2. Check if the “due_date_use_sip_date_format” (and similar) setting is 
relevant (it may not be, as you mentioned)

Although that explicitly references “due_date”, investigate whether there are 
separate settings for “hold_pickup_date” (CM) or recall_date that govern the 
format.

Check the admin UI under: Staff → Admin → Server → SIP → Account (and/or global 
SIP settings) for all relevant date-format flags.

3. Check whether the field (CM) is subject to a filter or override

The module Item.pod in the SIPServer code states that hold_pickup_date returns 
“standard SIP-format timestamp: MMDDHHMMSS” for that field.
list.evergreen-ils.org

But maybe in your installation a custom filter, patch, or configuration is 
truncating it.

Examine the “filter” table in the SIP schema (you noted it’s empty) — but maybe 
a custom code/plugin is intercepting the value.

Do you have SIPServer logging to share (with redacted usernames/passwords), 
other than the few snippets?

4. Test with other date-fields and requests

As you mentioned, the “transaction date” field reportedly is showing full 
precision, meaning the SIP server can output full timestamps.

If _only_ CM, and not other date fields, is short, that strongly suggests 
either a field-specific override or missing data (maybe the hold_pickup_date in 
the database is only storing a date without time).

5. Check in your ILS database where hold_pickup_date is stored: does the field 
include time component, or only date?

If the hold pickup date was inserted without a time component (or stored as a 
date rather than timestamp), the SIP server might fall back to outputting only 
MMDD.

If that’s the case, you could update existing data to include a time (even 
default like 00) and then retest.

Please let us know your outcome.

Best regards,
Lorne
churchillcomputing.com
___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]



___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-18 Thread Josh Stompro via Evergreen-general 
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

Returns the location of C<$patron_id> in the hold queue for the
189

item, with '1' indicating the next person to receive the item.  A
190

return status of '0' indicates that C<$patron_id> does not have a
191

hold on the item.
192

193

=item C<$date = $item-Erecall_date>
194

=item C<$date = $item-Ehold_pickup_date>
195

196

These functions all return the corresponding date as a standard
197

SIP-format timestamp:
198

199

MMDDHHMMSS
200

201

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 MMDD 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):
> 1720251101084453AOjabokkn|AB424480023074|
>
> Response to this request which we have received (with the CM field
> highlighted in bold):
> 1808020120251101092707AB424480023074|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: MMDDHHMMSS."
>
> 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:
>
> 
>
> 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 MMDD 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=335ba9848c620

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-17 Thread Lorne Churchill via Evergreen-general 
Hello Linda,

In case you have not found a solution yet, here are a few more things to check 
in order of easiest to deeper, to find & fix the root cause:

1. Verify that the SIP server is really reading the “use_sip_date_format” 
setting

Double-check the file path and whether that option is being picked up by the 
SIP server process.

Sometimes after editing SIPconfig.xml, a service restart (or complete 
stop/start) is required; ensure the config change actually took effect.

Monitor the SIP server startup logs for any warnings/errors about invalid 
config or unrecognized option.

2. Check if the “due_date_use_sip_date_format” (and similar) setting is 
relevant (it may not be, as you mentioned)

Although that explicitly references “due_date”, investigate whether there are 
separate settings for “hold_pickup_date” (CM) or recall_date that govern the 
format.

Check the admin UI under: Staff → Admin → Server → SIP → Account (and/or global 
SIP settings) for all relevant date-format flags.

3. Check whether the field (CM) is subject to a filter or override

The module Item.pod in the SIPServer code states that hold_pickup_date returns 
“standard SIP-format timestamp: MMDDHHMMSS” for that field. 
list.evergreen-ils.org

But maybe in your installation a custom filter, patch, or configuration is 
truncating it.

Examine the “filter” table in the SIP schema (you noted it’s empty) — but maybe 
a custom code/plugin is intercepting the value.

Do you have SIPServer logging to share (with redacted usernames/passwords), 
other than the few snippets?

4. Test with other date-fields and requests

As you mentioned, the “transaction date” field reportedly is showing full 
precision, meaning the SIP server can output full timestamps. 

If _only_ CM, and not other date fields, is short, that strongly suggests 
either a field-specific override or missing data (maybe the hold_pickup_date in 
the database is only storing a date without time).

5. Check in your ILS database where hold_pickup_date is stored: does the field 
include time component, or only date?

If the hold pickup date was inserted without a time component (or stored as a 
date rather than timestamp), the SIP server might fall back to outputting only 
MMDD.

If that’s the case, you could update existing data to include a time (even 
default like 00) and then retest.

Please let us know your outcome.

Best regards,
Lorne
churchillcomputing.com
___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-05 Thread Linda Jansová via Evergreen-general 

Hi,

We have checked the following tables:

https://egcatalog.larl.org/schemaspy/eg_3_13_6/sip/index.html

The filter table is just empty, so I'm just wondering whether it is 
actually used by the SIP server (configured according to instructions 
from 
https://docs.evergreen-ils.org/docs/latest/admin/sip_server.html#_configuring_the_server)? 



Also, SIP users are actually configured elsewhere 
(https://docs.evergreen-ils.org/docs/latest/admin/sip_server.html#_adding_sip_users) 
and the account table 
(https://egcatalog.larl.org/schemaspy/eg_3_13_6/sip/tables/account.html) 
is empty...


Perhaps that might be a clue?

Linda

On 11/3/25 07:18, Linda Jansová wrote:

Dear Lorne,

I have tried to list all that has been investigated so far...

I have just had a look at the database schema 
(https://egcatalog.larl.org/schemaspy/eg_3_13_6/sip/index.html) but it 
seems to me rather unlikely that the format of this particular field 
could be impacted this way (I might be mistaken, though).


Linda

 On 11/3/25 02:57, Lorne Churchill via Evergreen-general wrote:
Thank you Linda, it does seem there the "short date" could very well 
be situational. Which permissions/settings, other than those you 
mentioned, have you investigated so far?

___
Evergreen-general mailing list -- 
[email protected]
To unsubscribe send an email to 
[email protected]





___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-02 Thread Linda Jansová via Evergreen-general 

Dear Lorne,

I have tried to list all that has been investigated so far...

I have just had a look at the database schema 
(https://egcatalog.larl.org/schemaspy/eg_3_13_6/sip/index.html) but it 
seems to me rather unlikely that the format of this particular field 
could be impacted this way (I might be mistaken, though).


Linda

 On 11/3/25 02:57, Lorne Churchill via Evergreen-general wrote:

Thank you Linda, it does seem there the "short date" could very well be 
situational. Which permissions/settings, other than those you mentioned, have you 
investigated so far?
___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]



___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-02 Thread Lorne Churchill via Evergreen-general 
Thank you Linda, it does seem there the "short date" could very well be 
situational. Which permissions/settings, other than those you mentioned, have 
you investigated so far?
___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-01 Thread Linda Jansová via Evergreen-general 
I have just realized that actually the CM field appears to be used 
solely when requesting item information 
(https://docs.evergreen-ils.org/docs/latest/admin/sip_server_communication.html#sip_17-18_item_information 
and 
https://developers.exlibrisgroup.com/wp-content/uploads/2020/01/3M-Standard-Interchange-Protocol-Version-2.00.pdf; 
this is hopefully a more stable link to an external documentation 
describing the SIP 2 protocol).


Even the sample response to the request which I have shared earlier 
today shows that a transaction date uses the correct precision (it 
includes 18 chars as I have highlighted in bold in the response below):


18080201*20251101    092707*AB424480023074|AJTropika diskursu : 
kulturně kritické 
eseje|CK001|AQJAB-KN|APJAB-KN|BHCZK|BV0.00|BGJAB-KN|CF1|CM20251107|CTJAB-KN|CSFL-1.4/W|


So the SIP server is definitely capable of providing the long dates...

Linda

On 11/1/25 15:53, Linda Jansová wrote:

Thank you, Lorne!

We only have one pickup locker and at this stage we haven't tried any 
more sophisticated requests yet. I will report back once we have.


We have only added a single SIP account via the command line as 
detailed at 
https://docs.evergreen-ils.org/docs/latest/admin/sip_server.html#_adding_sip_users 
and have been able to log in successfully. This information, however, 
does not seem to be visible at 
/eg2/en-US/staff/admin/server/sip/account (if logged in at the 
consortium level)...


Linda

On 11/1/25 15:14, Lorne Churchill via Evergreen-general wrote:
Also, if you navigate to 
server/eg2/en-US/staff/admin/server/sip/account/new, there is a 
"due_date_use_sip_date_format" value, set by default to false.

___
Evergreen-general mailing list -- 
[email protected]
To unsubscribe send an email to 
[email protected]



___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-01 Thread Linda Jansová via Evergreen-general 

Thank you, Lorne!

We only have one pickup locker and at this stage we haven't tried any 
more sophisticated requests yet. I will report back once we have.


We have only added a single SIP account via the command line as detailed 
at 
https://docs.evergreen-ils.org/docs/latest/admin/sip_server.html#_adding_sip_users 
and have been able to log in successfully. This information, however, 
does not seem to be visible at /eg2/en-US/staff/admin/server/sip/account 
(if logged in at the consortium level)...


Linda

On 11/1/25 15:14, Lorne Churchill via Evergreen-general wrote:

Also, if you navigate to server/eg2/en-US/staff/admin/server/sip/account/new, there is a 
"due_date_use_sip_date_format" value, set by default to false.
___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]



___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-01 Thread Lorne Churchill via Evergreen-general 
Also, if you navigate to server/eg2/en-US/staff/admin/server/sip/account/new, 
there is a "due_date_use_sip_date_format" value, set by default to false.
___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[Evergreen-general] Re: Evergreen SIP server and a wrong date format in the CM (hold pickup date) field

2025-11-01 Thread Lorne Churchill via Evergreen-general 
Hello Linda,

A question - do you also see a "short" or long date upon checkin/checkout, 
hold, and renew activity with the locker? 
If you have other selfcheck-type machines on site, do they also provide short 
or long dates? 

It would be good to know whether the behaviour is "global"  - if not, that 
could provide a clue.

Best regards,
Lorne Churchill
https://gravatar.com/churchillcomputing
___
Evergreen-general mailing list -- [email protected]
To unsubscribe send an email to [email protected]