The timezone of the server is “Asia/Kolkata” and that of my browser is “Europe/Berlin” which is as intended.
If I set the server timezone to “Europe/Berlin” everything works as expected.
Thought this problems seems to be of theoretical nature it might be useful to fix it for the demo platform.
Here is what I have found out this afternoon about the causation of the problem:
(1) The AngularJS makes a REST request to “bahmnicore-omod” to create the patient. In this step the date of birth is transformed into a timestamp with the time-zone-offset from the server.
Request URL:https://192.168.33.10/openmrs/ws/rest/v1/bahmnicore/patientprofile
Request Method:POST
Status Code:200 OK
Remote Address:192.168.33.10:443
(2) The request for the patient details to the OpenMRS REST API doesn’t contain the time information anymore, but still the information about the time-zone-offset
Request URL:https://192.168.33.10/openmrs/ws/rest/v1/patientprofile/0d3876c3-cc0c-440b-b84c-ab7b8d5b0315?v=full
Request Method:GET
Status Code:200 OK
Remote Address:192.168.33.10:443
...
birthdate: "2015-02-19T00:00:00.000+0530"
...
We are already aware of Timezone issues in Bahmni – since we encountered them some months ago. Unfortunately the fixes are non-trivial, and we don’t expect production instances to currently encounter this issue. It usually happens in Demo instances – surely, and also when someone from a different timezone logs on to see data in another place — or someone installs Bahmni in a specific timezone but configures it for use in a different timezone.
Since usually Bahmni is installed within premises – its not an issue currently in production locations. It can become an issue easily for cloud based deployments (like the demo instance) running in different timezones.
I do not understand why there is a time and time zone attached to the date of birth at all.
These changes would fix the problem described in post #1 (and probably the one from post #3 , unfortunately I don’t know how to reproduce this today) as well:
It seems like you are not too excited about this workaround. The good thing about it is that it actually works, probably for all the problematic cases.
When searching for a better solution I found out that there is – from my point of view – a problem with the test case “should map birth date in dd-mm-yyyy format”. If you add a console.log statement after the patient mapping you will see that the birthdate is actually not in this format but still includes a time zone. It looks like this: “Sun Mar 05 2017 00:00:00 GMT+0100 (CET)” (see full object dump).
I tried to store a string with the format “DD-MM-YYYY” in the field patient.birthdate (see b50932). Unfortunately, Angular refuses to display such a string as date field (see stacktrace).
An acceptable workaround might be to configure the Angular date display in a way to it ignores the time and time zone (see stackoverflow.com). But I have to give up for today as vagrant suddenly fails to mount the source dir http://pastebin.com/EKTWGTmQ
Fixing the date issue is something I would like to see. But, unfortunately I don’t think it’s a simple fix. It may be simple for a particular screen, in which case you can raise a pull request for that, but overall the impact of dates is wide in Bahmni… since its integral to all screens – registration, consultation, document upload, reporting, etc. So - we will need to spend time testing that it works across all screens when client and server timezones are different.
Besides the demo server online, there hasn’t been a real usecase to actually cause us to spend the effort.
We may do it sometime in the future. Meanwhile if you have the bandwidth to raise a pull request to fix this, and have tested it sufficiently based on your usecases, please let us know. We will be happy to review/merge it.