Replace usages of joda time with java time [2]

[MartinWahnschaffe]

Problem Description

Since we had to rely to Java 7 for the SORMAS API, we are currently using joda time in the DateHelper and a few other classes. With #6686 we can now replace this dependency by the time API included in Java 8.

Proposed Change

1. Identify and replace all usages of joda time.
2. Replace and remove separate classes DateHelper8 with then existing methods in DateHelper or other relevant classes.

Acceptance Criteria

• [ ] All usages of joda-time are replaced (or removed if obsolete).
• [ ] joda-time as dependency is removed in all modules.
• [ ] Changed parts are covered by unit tests or documented what was tested manually.

Implementation Details

These examples shall help to replace joda time code.

Use case	java time example
Calculation	java.time.LocalDate.plusDays
Conversion	It's quite complex, reuse UtilDate helper from vitagroup (currently documented in german)
Comparison	java.time.LocalDate.isBefore
Distance	java.time.temporal.ChronoUnit.DAYS.between
Formatting	java.time.format.DateTimeFormatter.ofPattern(pattern).format

UtilDate acts as an easier to use bridge for conversion that mainly contains:

1. from methods to convert from java.time.* to java.util.Date.
2. to methods to convert from java.util.Date to java.time.*.
3. of methods to create a java.util.Date with primitive parameters for timestamp parts (mimics signatures like LocalDate.of.
4. helpers methods now, today, yesterday, tomorrow.

Additional Information

Used features of joda-time (50 imports in ~40 classes in sormas-api, sormas-backend, sormas-app, sormas-ui):

1. Calculation with LocalDate and DateTime
2. Conversion from and to java.util.Date
3. java.util.Date comparison
4. java.util.Date distances
5. Timestamp formatting

[StefanKock]

Many findings to be discussed, documented in PR

[StefanKock]

Current state:

1. joda-time is removed everywhere except in the android-app. -> to be done by @MartinWahnschaffe
2. Discussions solved, PR #9942 updated.

[MartinWahnschaffe]

@StefanKock Unfortunately we can't use this for the android app with current minimum version of Android API Level 24 (Android 7). It requires API Level 26 (Android 8): https://developer.android.com/about/versions/oreo/android-8.0#rt

This means we either have to:

A. Use API Level 26 as minimum - so no longer support Android 7 OR B. Keep joda Time and a local copy of the old DateHelper class in the android app.

Note: API 24 is currently supported by 95.1% of devices. API 26 is supported by 91.1% (https://apilevels.com)

[StefanKock]

A. Use API Level 26 as minimum - so no longer support Android 7

It's a product question whether it's an option to cancel support for older Android API levels 25 and 26.

B. Keep joda Time and a local copy of the old DateHelper class in the android app.

I think that's not possible. One example (but there are probably dozens): api.utils.EpiWeek.toString uses api.utils.DateHelper and I assume the android-app uses that toString method too. Even if we keep the old DateHelper class under the api.utils. path in the android-app I suspect it does change which DateHelper class is used inside the sormas-api.jar (similar problem described here: https://stackoverflow.com/questions/6564133/how-to-override-a-class-within-an-android-library-project ).

[MartinWahnschaffe]

I will get in contact with @zohaibhassan122 to clarify whether setting the minimum to level 26 (Android 8) is a viable option.

[faatihi]

Hi. Just to confirm, users of Android 7 in Ghana are not that many. And we're planning to upgrade them to at least Android 8, to prep for these changes.

[StefanKock]

It happens twice within 10 builds that the following test failed on Jenkins causing the CI to stop.

java.lang.AssertionError: 

Expected: <1439L>
     but: was <1440L>
	at de.symeda.sormas.api.task.TaskHelperTest.testGetDefaultDueDate(TaskHelperTest.java:24)

[StefanKock]

Fixed flaky test ( 67ef6dd)