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: YYYYMMDDZZZZHHMMSS” 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 YYYYMMDD. If that’s the case, you could update existing data to include a time (even default like 000000) 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]
