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]
