This ticket is a research spike to decide how we deal with times, dates and timezones, and to create the relevant tickets for additional work.

Is timezone in OpenLMIS set to GMT/Epoch or 'local time' — which would reflect the timezone of the MOH?
If timezones are stored in GMT, should the UI be responsible for translating that time to the user's local time? Would we want to expose functionality for a user to update their timezone?

From
Most of the dates we have, are specific points in time and a timezone applies. Ask what that specific timezone is. e.g. Is the period start date relative to the time zone the facility is in, or relative to the MoH headquarters? For timezones we need to use the appropriate Java type and we need to store the timezone in the database. We also need to serialize that timezone to clients (ISO8601 w/TZ or epoch) in a standard way.

When we don’t have a timezone, we tend to be talking about a “date” that isn’t a descrete point in time. e.g. an expiration date of a drug.

v2 had issues with all of this: the db tended to not store timezones. The system couldn’t understand a country which spread across timezones, etc

In the specific example given for the created date, we need a timezone as this is the universal date, time, milliseconds that the requisition was created - I’m good with using epoch style here or a string format of ISO8601 that’s applicable.

From
Regarding datetimes, we can store in epoch and I guess that's what we are doing currently, but once we turn that into a LocalDateTime object, there is a timezone used for that

From Brandon:
It's important to make sure we are clear about our intended design at every layer:

• how are times, dates and timezones stored in persistent storage?

• what kind of Java data type do we use to manipulate, compare, and apply business rules on them?

• how do the services expose them in the APIs (and how do we specify this in RAML)?

• how are they serialized in the JSON?

• how does the front-end AngularJS code interpret and use them?

• how does the UI display times, dates, and timezones to end users?

• It's also important we be clear on the following:

• are there per-user preferences for each user account's local time zone?

• if so, how do we apply each user's local time zone preference when displaying times and dates?

• what about translation or different formatting conventions (3/15/2016 versus 15-3-2016)?

Acceptance Criteria

• Agreement on how times, dates and timezones are handled in each layer of the system (storage, backend, exposed in APIs, handled in AngularJS UI, and exposed to users).

• A wiki page documenting how OpenLMIS 3 handles times, dates and timezones. This will be an important guide for development of future services, extensions and customizations.

• Created any follow-up tickets to bring the existing v3 codebase into conformity with this decision.