946090 - datetime custom fields don't adjust to user's display timezone

Status: REOPENED

(Bugzilla :: User Interface, enhancement)

Description

[Simon Green]

Attachment: time-v1.patch

(from the brc bug):
Description of problem:
In the Preferences page, there is a setting for "Timezone used to display dates and times".  If I set a value for this, most times are displayed correctly in my selected timezone, but the Last Closed field is not.

Version-Release number of selected component (if applicable):
4.4.0009

How reproducible:
Always

Steps to Reproduce:
1. Go to https://bugzilla.redhat.com/userprefs.cgi
2. Change the "Timezone used to display dates and times" field to "Australia/Brisbane"
3. Go to https://bugzilla.redhat.com/show_bug.cgi?id=950315

Actual results:
Reported and Modified dates are correctly shown with EST timezone, but Last Closed is shown with no timezone (and thus differs from Modified by 14 hours).

Expected results:
all dates and times should be shown adjusted for the user's selected timezone.

Additional info:
none.

Comment 1

[Simon Green]

Should mention that this change applies to non-editable datetime custom fields. I haven't touched editable custom fields, because I assume they should be in the server time.

Comment 2

[Frédéric Buclin]

Comment on attachment 8342193 [details] [diff] [review]
time-v1.patch

(In reply to Simon Green from comment #1)
> Should mention that this change applies to non-editable datetime custom
> fields. I haven't touched editable custom fields, because I assume they
> should be in the server time.

This inconsistency doesn't make sense. When someone enters a date+time value, there is no assumption about what the timezone is (user timezone? server timezone?), and the validator doesn't even look at any timezone at all. So converting a value which is timezone-agnostic must not be converted to any other timezone as you don't even know which timezone the user had in time when typing it. This would bring more confusing than it would be helpful. If the time entered by the user was clearly in his own timezone and the validator was converting this time to the server timezone, then this would be another story.

Comment 3

[Frédéric Buclin]

IMO, this bug is WONTFIX, and certainly not a bug applicable to a stable branch.

Comment 4

[Frédéric Buclin]

Several typos in my previous comment (oops!). It should be:

So a value which is timezone-agnostic must not be converted to any other timezone as you don't even know which timezone the user had in mind when typing it. This would bring more confusion than it would be helpful.

Comment 5

[Simon Green]

(In reply to Frédéric Buclin from comment #3)
> IMO, this bug is WONTFIX, and certainly not a bug applicable to a stable
> branch.

Fair enough. The use case for brc is the 'last closed' custom field, which is not user editable, and set by the system. This means we know it is stored in the system timezone. brc will carry the patch locally.

  -- simon

Comment 6

[Simon Green]

(In reply to Frédéric Buclin from comment #2)
> So converting a value which is timezone-agnostic must not be converted
> to any other timezone as you don't even know which timezone the user had in
> time when typing it. This would bring more confusing than it would be
> helpful. 

Currently the value is being converted from server time to UTC via RPC. Should I file a bug to fix that issue? If we aren't changing the UI, then RPC should show consistent behaviour too.

Comment 8

[Fedor Ezeev]

(In reply to Frédéric Buclin from comment #2)
> When someone enters a date+time
> value, there is no assumption about what the timezone is (user timezone?
> server timezone?)

When someone enters a date+time - he enters it in user timezone, obviously. Why he would (or should) calculate local time into server timezone? He even doesn't know server timezone in most cases.

Comment 9

[Frédéric Buclin]

(In reply to Fedor Ezeev from comment #8)
> When someone enters a date+time - he enters it in user timezone, obviously.
> Why he would (or should) calculate local time into server timezone? He even
> doesn't know server timezone in most cases.

Because his company asks him to do so? E.g. a field label such as "ETA (UTC):" would be pretty explicit, and independent of the user's timezone or the server timezone. I don't think it's a good idea to enforce this.

Comment 12

[TonyT]

Dylan, Frederick,
    I am the create of below duplicate bug. 
Bug 1296759 - Custom date field- Timezone conversion

I will wait for the bug Dylan mentioned in my Bug . 

Thanks 
Tony

Comment 13

[TonyT]

Dylan,
    I am the one who created 1296759 .Please let me know if the fix for this is ready ? I remember you saying you are building and tasting a patch last weekend .


Thanks 
Tony

Comment 14

[TonyT]

Would you please check and let me . Or should I update the bug i created initially to move this forward?

Comment 15

[Andre Klapper]

No as "your" report is a duplicate. 
Any potential further discussion has to happen in a single place: bug 946090.

Comment 16

[TonyT]

Dylan,
   I know this is an open source and you are volunteering. But would like to know if this is achievable or not in near future. Our decision to start using this product is depending on this. This is a real showstopper for our decision.

Thanks 
Tony

Comment 17

[TonyT]

Can I get an update on this . I really appreciate it.

Comment 18

[TonyT]

Hi Dylan,
  If this fix is something minor can you please expedite this ? This is the only showstopper for us to finalise the tool .

Thanks 
Tony

Comment 19

[Andre Klapper]

TonyT: Feel free to contact the assignee directly via email, as your last six comments were sent to //all// subscribers on this task. Thanks for your understanding.

Comment 20

[TonyT]

Please let me know the status ? Can we expect a fix soon ?

Tony

Comment 21

[Mark A. Ziesemer]

This is impacting me as well.  For me, the most significant of this is the same as comment #6, regarding the REST API / RPC.  As-is, this returns default date fields (e.g. creation_time) and custom date fields (cf_*) that are all identically formatted, and as UTC ('Z').  There are no clues that the default date fields are correct, and that the custom fields are off by as much as 24 hours.

Worse, there isn't a great way to correct for this.  I can have the client code convert these timestamps as UTC back to the database timezone, and then discard the timezone offset to at least attain consistency with what is displayed on the UI - and what was actually entered by the user.  The worst part about this hack is that I have to code in an assumption of what the database timezone is - which is what the RPC seems to be using for the conversions it is applying here.  Everything returned by /rest/time is also all UTC, so I have no way to dynamically determine what timezone RPC is converting these timestamps from:

{
   "db_time" : "2017-03-17T04:15:00Z",
   "tz_name" : "UTC",
   "tz_offset" : "+0000",
   "tz_short_name" : "UTC",
   "web_time" : "2017-03-17T04:14:59Z",
   "web_time_utc" : "2017-03-17T04:14:59Z"
}

Having something like db_time showing the actual offset, and then db_time_utc would have been quite helpful here.

Now, this all assumes that myself and the user-base have been entering timestamps local to the timezone of the database.  (Ideally, as per bug #452353, everything in the database would also be normalized to UTC.)  Comment #2, comment #8, and comment #9 need to be considered to ensure that the input is accounted for as well as the output - as right now, it is completely ambiguous in terms of the time zone.