EDIT

Andreas Müller wrote:

1) If one uses the datepicker on a system which differs from the local date inconsistent results show up.

E.g. if , on PESI-HPC, I pick a datetime 31/7/2017 00:00 it is stored as 30/7/2017 22:00.

On my machine the same problem occurs. The datetime from the dialog has time zone Europe/Berlin, on my machine the time zone is set to (UTC+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien and for the mysql instance the time zone is set to the system time zone.
But nevertheless the stored date is 2 hours less then the chosen one.
reload the date shows again the right date.

now all DateTime/ZonedDateTime objects use a timezone offset of 0:00.

I already moved the dateTime objects to ZonedDateTime and wrote a converter for the time until the cdmlib uses java.time, too.

Katja Luther wrote:

now all DateTime/ZonedDateTime objects use a timezone offset of 0:00.

I already moved the dateTime objects to ZonedDateTime and wrote a converter for the time until the cdmlib uses java.time, too.

During standup we decided not to move to java.time for if not necessary.

Andreas Müller wrote:

With the current solution when storing e.g. 2017-09-14 00:00 and reloading it shows 2017-09-14 02:00. This is worse then storing the time with timezone biased in the DB. The time should generally be interpreted as local time. Is this possible with current usage of joda time?

In cdmlib zonedDateTime is used, so we need to switch to LocalDateTime in cdmlib

sorry, moved to conversion to UTC timezone to the dateElement. Now it works for all DateElements.