bug #6860
closed
Use consistent calendar system for date picker
Added by Andreas Müller over 6 years ago.
Updated over 6 years ago.
Description
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.
2) When filling the datepicker for the first time, it gets second information. But seconds can not be edited. However, second information is stored in the database. I think we should completely remove second information (e.g. by always setting it to 00 if not possible otherwise).
3) We may also want to offer a "set hh:mm to 00:00" button to allows easily removing and time information. But maybe this is sufficiently handled by #6741
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.
- Status changed from New to Resolved
- Assignee changed from Katja Luther to Andreas Müller
- % Done changed from 0 to 80
maybe we should discuss whether ZonedDateTime is needed or it would be better to use LocalDateTime?
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.
- Status changed from Resolved to Feedback
- Assignee changed from Andreas Müller to Katja Luther
- % Done changed from 80 to 60
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?
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
- Status changed from Feedback to Resolved
- % Done changed from 60 to 50
- % Done changed from 50 to 60
should be solved now. the UTC timezone is now used for reading.
- Assignee changed from Katja Luther to Andreas Müller
- Status changed from Resolved to Feedback
- Assignee changed from Andreas Müller to Katja Luther
The given solution seems to work only for Media.createDate. However there are other places where the DateTime and the DatePicker is used such as Reference.accessed (for a list see https://dev.e-taxonomy.eu/redmine/issues/6658#note-9).
Is it possible to implement this in something like the Datepicker base class to guarantee that it is always correctly handled whenever a DateTime is edited (and no zoned time is wanted)?
sorry, moved to conversion to UTC timezone to the dateElement. Now it works for all DateElements.
- Status changed from Feedback to Resolved
- Assignee changed from Katja Luther to Andreas Müller
- Status changed from Resolved to Closed
- Assignee changed from Andreas Müller to Katja Luther
- % Done changed from 60 to 100
Seems to work correctly now.
Also available in: Atom
PDF