Error saving datetime Obs

Hi:

I noticed that when I try to save an observation whose Concept is a “DateTime” of class “Misc” via the Web Services, it fails. If I use a different DateTime Concept of type “Question”, it works!. The failure is caused by a date format parsing issue. The class “Misc” doesn’t like the format that I am sending of “2017-02-01T00:00:00.000-0500”.

here’s the error:

java.lang.reflect.Method.invoke(Method.java:606)\n\tat
org.openmrs.module.webservices.rest.web.resource.impl.BaseDelegatingResource.setProperty(BaseDelegatingResource.java:727
)\n\t... 67 more\nCaused by: java.text.ParseException: Unparseable date: \"2017-02-02T00:00:00.000-0500\"\n\tat
java.text.DateFormat.parse(DateFormat.java:357)\n\tat org.openmrs.Obs.setValueAsString(Obs.java:1039)\n\tat
org.openmrs.module.webservices.rest.web.v1_0.resource.openmrs1_8.ObsResource1_8.setValue(ObsResource1_8.java:384)\n\t...
71 more\n"}}

What am I going wrong?

Thanks,

Joe

I’d imagine that it should work regardless of the concept class, why can’t you set the class to question anyways?

@jcelano as Wyclif says, nothing in the code cares about concept class when saving obs. (We do switch on the concept datatype.) There must be some other difference between those two concepts…

Actually, looking more closely at the Concept types, the one that works is Date, while the one that fails is Datetime. Is there a different format for Datetime?

The difference is Date expects no time component in the date string while Datetime does include it.

Got it, thx! I needed to make the format like this “yyyy-MM-dd HH:mm” for it to work.

Apparently with REST you need to submit that date value in the servers time zone since the timezone component is rejected.

That sounds like a bug that we should file and fix…

A quick fix would be in the REST module so that it parses the date and sets it via Obs.setValueDatetime() or Obs.setValueDate() instead of Obs.setValueAsString(), then we can also have it addressed in core as a longer term fix.

I have created TRUNK-5025 but we can have a work around in the REST module to fix it see RESTWS-644

Has this issue been resolved? Cause it’s still open in the issue tracker.