Date(Time)Pickers - sort out the time part

Description

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)

Environment

None

Activity

Show:
Chongsun Ahn
August 15, 2017, 10:01 PM

Yeah, it looks like it's supposed to be a date type.

Paweł Gesek
August 16, 2017, 10:30 AM
Edited

These are the stock management fields that are suspect:

http://ci.openlmis.org/erd-stockmanagement/stockmanagement/tables/physical_inventories.html
http://ci.openlmis.org/erd-stockmanagement/stockmanagement/tables/stock_card_line_items.html
http://ci.openlmis.org/erd-stockmanagement/stockmanagement/tables/stock_event_line_items.html

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.

http://ci.openlmis.org/erd-stockmanagement/stockmanagement/tables/stock_events.html
http://ci.openlmis.org/erd-stockmanagement/stockmanagement/tables/stock_card_line_items.html

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?

Paweł Gesek
August 16, 2017, 7:26 PM
Edited

https://github.com/OpenLMIS/openlmis-requisition/blob/master/src/main/java/org/openlmis/requisition/web/RequisitionController.java#L285

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)

Paweł Gesek
August 16, 2017, 7:28 PM
Edited

The third issue is the POD you already mentioned, I am not aware of more places, but it's possible they exist.

Paweł Albecki
September 1, 2017, 9:13 AM
Edited

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.

Done

Assignee

Mateusz Kwiatkowski

Reporter

Paweł Gesek

Labels

None

Story Points

3

Time tracking

0m

Time remaining

0m

Components

Sprint

None

Fix versions

Priority

Major