I have just been able to reproduce it like this when i change my time zone to his as below:
Date day = new Date();
DateTimeZone timeZone = DateTimeZone.forID(“Europe/Moscow”);
System.out.println(new DateMidnight(day, timeZone).toDate());
The output is: Mon Jan 30 23:00:00 EAT 2017 (with joda-time version 2.3)
While the output is: Tue Jan 31 00:00:00 EAT 2017 (with joda-time version 2.9.2)
The second output is the correct one because it is already after midnight (12:40 AM) and hence Tue instead of Mon.
The false output does not surprise me because DateMidnight is deprecated as of version 2.3 of joda-time, with the message: The time of midnight does not exist in some time zones where the daylight saving time forward shift skips the midnight hour…
I can see that this class is used in various modules with various versions of joda-time as below:
webservicesrest = joda-time version 2.9.2
emrapi = joda-time version 2.2
reporting = joda-time version 2.3
And possibly more…
So my recommendation is that we upgrade joda-time version to at least that used by webservicesrest
Any objections or alternative suggestion?
As to why each of these modules bundles joda-time, that is possibly for another day.
I agree that we should upgrade the joda-time versions of any OpenMRS-maintained modules. The current version is 2.9.7 so I don’t see a reason to use something lower.
Further, if someone is going to the effort, maybe they should fix usages of DateMidnight in those modules also. (Specifically: emrapi, calculation, htmlformentry, htmlformentryui, and ebolaexample.) The deprecation notice says the following, and I assume the fixes should be easy:
Use LocalDate to represent a date without a time zone. Or use DateTime to represent a full date and time, perhaps using DateTime.withTimeAtStartOfDay() to get an instant at the start of a day.
The reason we used joda-time is that it’s way better than java.util.Date class and related utilities. The reason we decided not to integrate it into openmrs-core is that Java 8 introduces better date/time classes under java.time, and thus Joda is no longer needed (at least, once the minimum supported OpenMRS Platform version is 2.0.x).
The standard date and time classes prior to Java SE 8 are poor. By tackling this problem head-on, Joda-Time became the de facto standard date and time library for Java prior to Java SE 8. Note that from Java SE 8 onwards, users are asked to migrate to java.time (JSR-310) - a core part of the JDK which replaces this project.
I was as able to perfectly reproduce the problem that @jackgin reported by simply appending the VM argument -Duser.timezone=Europe/Moscow to my standalone instance.
So the easiest fix is the commit i have done for https://issues.openmrs.org/browse/EA-118@jackgin, i have attached the fixed compiled module “emrapi-1.21-SNAPSHOT.omod” on this ticket. Just delete the “emrapi-1.18.omod” which comes with the OpenMRS 2.5 Standalone in appdata/modules and replace it with “emrapi-1.21-SNAPSHOT.omod”. I have tested and confirmed that this works well.
I agree with updating to the latest Rest web services module, and, beyond that, we consider fixing the code that uses DateMidnight, though I do feel like I’ve used it in several places.
@dkayiwa Whereas your patch indeed fixes the visit date shown on the left, the problem essentially persists. Recording any vitals or diagnosis is still impossible with the same error,
Encounter datetime should be after the visit start date.
@jackgin did you restart the standalone? Did you remember to delete the old emrapi module?
I did the above and tested with your time zone to confirm it works.
On the same ticket, i have attached an updated version of the htmlformentry module, which also had an older joda-time version. Can you replace htmlformentry-3.3.0.omod with htmlformentry-3.3.2-SNAPSHOT.omod which you can find attached on the ticket? Then test again and tell us how it goes.
@dkayiwa I replaced the htmlformentry module. The ‘encounter datetime should be after…’ error no longer occurs. However, when trying to save the vitals I see the popup “Unexpected error, please contact your System Administrator: error”. The vitals I am trying to save get the green check mark like they are recorded, but when I end the visit, no vitals are actually saved. Here is the tomcat log:
_upload.ee/files/6620265/2017-1-31.log.html
I am facing the same problem. My OpenMRS standalone version is 2.9.0 and java 8. I tried to replace modules created by @dkayiwa although these are older than by my modules version, but it cannot solve the problem. I am running on Ubuntu 18.04.
As @jackgin’s problem.
" I login as a doctor in an outpatient clinic (using a preset account), open a visit for an existing (preset) patient and chose ‘Capture vitals’. However, when I try to save the vitals, I obtain the following message: “Encounter datetime should be after the visit start date”. As a result, I can not save the vitals, and diagnosis, etc. "
