Project

General

Profile

bug #6860

Use consistent calendar system for date picker

Added by Andreas Müller over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
New
Assignee:
Category:
taxeditor
Target version:
Start date:
07/31/2017
Due date:
% Done:

100%

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 view Closed 05/20/2017
Related to Edit - feature request #6741: Edit Date in TextField New 06/20/2017
Related to Edit - feature request #6920: [DISCUSS] use ZonedDateTime (java8) instead of joda time New 08/22/2017

Associated revisions

Revision dc12a332 (diff)
Added by Katja Luther over 1 year ago

ref #6860: use timezone offset 0 and change joda DateTime to ZonedDateTime, until in lib DateTime is still joda a converter is used

Revision 8b5ab7b2 (diff)
Added by Katja Luther about 1 year ago

fix #6860: add UTC timezone also to reading from entity in DateElement

Revision 82a099cf (diff)
Added by Katja Luther about 1 year ago

initial time of date element needs to be UTC timezone

History

#1 Updated by Katja Luther over 1 year 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.

#2 Updated by Katja Luther over 1 year 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.

#3 Updated by Katja Luther over 1 year 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?

#4 Updated by Andreas Müller over 1 year 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.

#5 Updated by Andreas Müller over 1 year 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?

#6 Updated by Katja Luther over 1 year 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

#7 Updated by Katja Luther about 1 year ago

  • Status changed from Feedback to Resolved
  • % Done changed from 60 to 50

#8 Updated by Katja Luther about 1 year ago

  • % Done changed from 50 to 60

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

#9 Updated by Andreas Müller about 1 year ago

  • Assignee changed from Katja Luther to Andreas Müller

#10 Updated by Andreas Müller about 1 year ago

#11 Updated by Andreas Müller about 1 year ago

#12 Updated by Andreas Müller about 1 year 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)?

#13 Updated by Katja Luther about 1 year ago

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

#14 Updated by Andreas Müller about 1 year ago

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

#15 Updated by Andreas Müller about 1 year ago

#16 Updated by Andreas Müller about 1 year 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)