Our datepickers currently always send the time part underneath (defaulting to 00:00), which can lead to unexpected behavior:
The 'to' date in the view requisitions is exclusive, as in a requisition made on that date will not be returned
Stock Management and Fulfillment (POD) have inputs for date times, but the time part is silently added underneath and persisted on the backend. If we don't need it we should drop it on the backend (ZonedDateTime -> LocalDateTime) or allow entering the time in the datepicker if it makes sense to persist the time.
The ideal solution might be done on a per case basis (i.e. we drop time here, but allow setting it there)
Yeah, it looks like it's supposed to be a date type.
These are the stock management fields that are suspect:
In the schemas above, the field occurreddate is a timestamp. We have inputs for this field on the stock UI. The UI sends a midnight time part for it underneath, you only select the date on the UI.
In the schemas above, the field processeddate is a timestamp, but I can't find where this field is used, seems UI doesn't send it. Are we using it all?
RequisitionController, method search. The parameters initiatedDateFrom and initiatedDateTo are ZonedDateTimes. They are used to search against the initiated time aka createdDate (which is a ZonedDateTime). On the UI however, the user does not select the time part, it is set to 00:00:00 for him. Which means if he selects from 14th to 16th August, it will search from 14th August 00:00 to 16th August 00:00 - the upper boundary he selects is exclusive (unless the requisition was created precisely at midnight)
The third issue is the POD you already mentioned, I am not aware of more places, but it's possible they exist.
Requisition search by created date doesn't use time part anymore so if user selects from 14th to 16th August, it will search from 14th August 00:00 (including) to 17th August 00:00 (excluding)
receiveddate for POD manage and occured date for physical inventory, stock events and stock cards doesn't use time part anymore, both UI and backend.
About processeddate, it needs to be zoned date time, user don't have to pass it because server set it for currect datetime. Yes, we are using this field.
Database migrations for remove time part from date works properly.