Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Update dates in Fulfillment to match timezone design

Description

Change date implementation in the Requisition code to match our new dates with timezone design. (https://openlmis.atlassian.net/wiki/display/OP/OpenLMIS+v3+Timezone+Spike)

Affected code (do not assume this is comprehensive):

  • FacilityDto, ProcessingPeriodDto, ProcessingScheduleDto

  • LocalDatePersistenceConverter, LocalDateTimePersistenceConverter - uses LocalDate and java.sql.Date

  • ProofOfDelivery

    • receivedDate - LocalDate (instant date)

  • OrderCsvHelper - uses LocalDate and LocalDateTime for order file columns

  • Order

    • createdDate - LocalDateTime (instant date)

  • OrderService - uses LocalDateTime from order

Acceptance Criteria

  • All business dates should be of type date in the database, LocalDate in the Java backend code and serialize to an ISO-8601 string (w/o time information) via the API

  • All instant dates should be of type timestamp with timezone in the database, ZonedDateTime in the Java backend code and serialize to an ISO-8601 string (with time and UTC timezone information) via the API

  • java.util.Date should not be used, but LocalDate should be used instead

Confluence content

mentioned on

QAlity Plus - Test Management

Checklists

Activity

Chongsun Ahn 
February 2, 2017 at 4:53 PM

It is a bit hard to understand. Here's the timezone document: https://openlmis.atlassian.net/wiki/display/OP/OpenLMIS+v3+Timezone+Spike. So we have LocalDate for business dates and ZonedDateTime for instant dates.

A business date is just a date on the calendar, which means it does not mean the same thing in different timezone contexts. When I say 2017-01-01 (January 1st, 2017), that means something different in Gdynia vs. Seattle, even if we attach a time to it, because we are in different timezones. So a Facility's goLiveDate does not tell us exactly when that facility went live, unless we attach a timezone, like the Facility's timezone, to it. We do not have to attach the timezone of the Facility to the date, and if we use another timezone (like timezone of the JVM), that could mean a different time. (In this case, the Facility's goLiveDate makes the most sense with the timezone of the Facility.)

An instant date is different because it does have the same meaning even in different timezone contexts. When I say an Order has a createdDate of 2017-01-01 00:00:00 UTC (January 1st, 2017, midnight UTC), then I know exactly when it was created. If I'm in Seattle or Gdynia, I know exactly when it was created and how long ago it was.

Does this help?

Jakub Hopen 
February 2, 2017 at 3:52 PM

I have a question about what date should be what type. I am not sure when to use LocalData and when ZonedDateTime ie why createdDate in Order should be ZonedDateTIme but goLiveDate in FacilityDto LocalDate? Could you explain this to me?

Done
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Story Points

Original estimate

Time tracking

1d 2h 30m logged1d 5h 30m remaining

Components

Sprint

Fix versions

Priority

Parent

Time Assistant

Created January 9, 2017 at 10:44 PM
Updated February 6, 2017 at 1:52 PM
Resolved February 6, 2017 at 1:51 PM