...
- Persistent Storage - in the processing_periods table, there would be a startdate column of type date.
- Java Backend Code - in the ProcessingPeriod object, there would be a startDate field of class LocalDate. When persisting, startDate would be stored as date. When retrieving, the a LocalDate object would be created based on the date, which is then used for startDate.
- If the startDate needed to be compared to now, to see if the processing period had already started, LocalDate.now(timezone) would be used to get a LocalDate version of now. The timezone specified would be the implementation default configuration setting (or facility timezone setting if there was one). Then the now LocalDate would be compared to startDate to determine if the startDate was before (or at) the now date.
- API Interface
- Serialization: the "best guess" timezone would be determined first. In this case, it would be the implementation default time zone. (If the facility had a timezone profile, that would be used instead.) A new ZonedDateTime object would be created using startDate and the implementation default timezone. This would be converted convert the LocalDate into a String of ISO-8601 format, then returned return in the response.
- Deserialization: convert the String into a LocalDate object. This is what is assigned to startDate.
- Frontend Client
- When displaying to the user, use the date as-is.
- When calling the APIs, make sure the date does not have time or timezone information.
- To compare the start date with now, the frontend client would do something similar as described in the Java Backend Code section, except using JavaScript date objects and methods.
...