Project

General

Profile

Actions

bug #6860

closed

Use consistent calendar system for date picker

Added by Andreas Müller over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
New
Assignee:
Category:
taxeditor
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Severity:
normal
Found in Version:

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


Related issues

Related to EDIT - feature request #6658: Make mediaCreated editable in Media viewClosedKatja Luther

Actions
Related to EDIT - feature request #6741: Edit Date in TextFieldNewKatja Luther

Actions
Related to EDIT - feature request #6920: [DISCUSS] use ZonedDateTime (java8) instead of joda timeNewKatja Luther

Actions
Actions #1

Updated by Katja Luther over 6 years ago

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.

Actions #2

Updated by Katja Luther over 6 years ago

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.

Actions #3

Updated by Katja Luther over 6 years ago

  • 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?

Actions #4

Updated by Andreas Müller over 6 years ago

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.

Actions #5

Updated by Andreas Müller over 6 years ago

  • 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?

Actions #6

Updated by Katja Luther over 6 years ago

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

Actions #7

Updated by Katja Luther over 6 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 60 to 50
Actions #8

Updated by Katja Luther over 6 years ago

  • % Done changed from 50 to 60

should be solved now. the UTC timezone is now used for reading.

Actions #9

Updated by Andreas Müller over 6 years ago

  • Assignee changed from Katja Luther to Andreas Müller
Actions #10

Updated by Andreas Müller over 6 years ago

Actions #11

Updated by Andreas Müller over 6 years ago

Actions #12

Updated by Andreas Müller over 6 years ago

  • 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)?

Actions #13

Updated by Katja Luther over 6 years ago

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

Actions #14

Updated by Andreas Müller over 6 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Katja Luther to Andreas Müller
Actions #15

Updated by Andreas Müller over 6 years ago

Actions #16

Updated by Andreas Müller over 6 years ago

  • 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.

Actions

Also available in: Atom PDF