[HTML Form Entry] Use <obsFromFragment> datetimepicker value as encounter datetime

Tags: #<Tag:0x00007ff4bdc42228> #<Tag:0x00007ff4bdc42138> #<Tag:0x00007ff4bdc41ff8>

Hello,

We are using <obsFromFragment> with commons-ui-datetimepicker in our HTML forms at multiple places. At certain places, we want to use the selected datetime value as encounterDatetime. Is it possible to use some store some <obs> value as encounter_datetime and not store as obs?

Below is how it is defined:

<obsFromFragment
        fragment="field/datetimepicker"
        provider="uicommons"
        conceptId="12345"
        initFragmentParamName="defaultDate"
       fragmentParams="formFieldName=assessmentDate/>

We want to avoid the the <encounterDatetime> tag for selection since it looks a totally different control on the UI.

CC: @mksd @ssmusoke @dkayiwa @rrameshbtech @vasanth2019

@mogoodrich would it be conceivable to upgrade the datetime picker widget behind <encounterDatetime/>?

@mddubey, the thing is <obs*/> tags record obs, and I think it should stay that way.

1 Like

Yes @mksd. Sure, it should be like that. Just checking if there was a way to say use this obs value as datetime.

@mksd @mogoodrich,

While using the datetimepicker with endDate param, it is leading to strange behaviour in a locale other than en.

This is how it looks like in when the locale is fr.

image

The start date is December 1989. If we remove the parameter endDate=$formGeneratedDatetime it all works fine.

While debugging the htmlFormEntry module, I found out we are setting the value as below in FormEntrySession.java:

velocityContext.put("formGeneratedDatetime", new Date());

Should this be somehow locale-sensitive/format-sensitive date? We have not been able to get it working.

CC: @dkayiwa @ssmusoke

@mddubey our distro might be doing some funny things with date formats, confusing the date picker. Can you validate that this also happens on QA Ref App?

Update - We have analysed the root cause of this issue.

Findings:

Whenever we configure an endDate/startDate to date time picker, internally in its set method - it will try to parseDate (its own scope method).

But while parsing the date, if the assigned value doesn’t match with any 4 regular expression mentioned below (Date formats) - it will try to create new Date object and assign the properties like date, year - one by one.

 if (/^\d{4}\-\d{1,2}\-\d{1,2}$/.test(date)) {
    /‘yyyy-mm-dd’/ - logic
  }
  else if (/^\d{4}\-\d{1,2}\-\d{1,2}[T ]\d{1,2}\:\d{1,2}$/.test(date)) {
    /‘yyyy-mm-dd hh:ii’/ - logic
 }
  else if (/^\d{4}\-\d{1,2}\-\d{1,2}[T ]\d{1,2}\:\d{1,2}\:\d{1,2}[Z]{0,1}$/.test(date)) {
    /‘yyyy-mm-dd hh:ii:ss’/ - logic
  }
  else if (/^[-+]\d+[dmwy]([\s,]+[-+]\d+[dmwy])*$/.test(date)) {
  /logic
  }

In this case for other languages, our assigned value is not matching with their formats and it is going for last flow.

For creating the date object, code used here is “date = new Date(0, 0, 0, 0, 0, 0, 0)”.

Since this value of this date object will be “Sun Dec 31 1899 00:00:00 GMT+0521 (India Standard Time)”, this base value for further operation end in setting the date value is “Sun Dec 31 1899 00:00:00 GMT+0521 (India Standard Time)”.

Fix : Ideal fix for his issue, instead of using “new Date(0, 0, 0, 0, 0, 0, 0)” - “Sun Dec 31 1899 00:00:00 GMT+0521 (India Standard Time)”, we should use new Date();

For reference: This issue is already observed by others and bootstrap have fixed this in their later versions.

Thanks for the details @vasanth2019. Do I understand correctly that we have two options:

  1. Upgrade UICM Bootstrap datetime picker.
  2. “Backport” the new Date() fix in the current UICM Bootstrap datetime picker.

Option 2 is a bit sketchy but is a fallback if anything goes wrong with option 1, correct?

Yes, Option 2 looks more safe and good for fallback. Will create a card in OpenMRS Jira and fix the same.

For the record here, there is a ticket for this, UICM-93.