Fix dates mismatch issue where dates for observation’s displayed in the Graph and Table view’s don’t match the observation’s effectiveDateTime as received by the app from service. #43
Issue : The open source version of growth chart has a mismatch in the observations (i.e height, weight etc) being displayed on the Graph and Table Views. After some investigation, the issue seems to be with the way the app processes date for an observation.
The app converts the dateString received from the resource call into Age in Months using the XDate library. Then the app converts the Age in Months back to a dateString for displaying it on the Graph and Table View for that observation. The XDate library computes this dateString incorrectly thus resulting in a date which could be off by a few days from the actual date of the observation.
More Info on this Issue : smart-on-fhir#35
Fix : This PR fixes the display to consume the effectiveDateTime received with the observation as a string. We pass down a separate key dateString with the application's object for observations and use it later on to display the string directly thus avoiding any conversions using the XDate library. This does not affect any calculation in the application.
Consideration: This fix uses a new variable dateString and does not alter any of the apps existing logic to handle a date object for an observation. This helps in keeping the dateString of the observation's completely separate from any calculations/computations in the app.
Issue : The open source version of growth chart has a mismatch in the observations (i.e height, weight etc) being displayed on the Graph and Table Views. After some investigation, the issue seems to be with the way the app processes date for an observation. The app converts the
dateString
received from the resource call intoAge in Months
using the XDate library. Then the app converts theAge in Months
back to adateString
for displaying it on the Graph and Table View for that observation. The XDate library computes thisdateString
incorrectly thus resulting in a date which could be off by a few days from the actual date of the observation.More Info on this Issue : smart-on-fhir#35
Fix : This PR fixes the display to consume the
effectiveDateTime
received with the observation as a string. We pass down a separate keydateString
with the application's object for observations and use it later on to display the string directly thus avoiding any conversions using the XDate library. This does not affect any calculation in the application.Consideration: This fix uses a new variable
dateString
and does not alter any of the apps existing logic to handle a date object for an observation. This helps in keeping thedateString
of the observation's completely separate from any calculations/computations in the app.