Bug 1315172 - Dashboard timezone is not valid by default
Dashboard timezone is not valid by default
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-django-horizon (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 7.0 (Kilo)
Assigned To: Alvaro Lopez Ortega
Ido Ovadia
: ZStream
Depends On:
  Show dependency treegraph
Reported: 2016-03-07 02:14 EST by Chen
Modified: 2016-11-30 11:59 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-11-30 11:59:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1554522 None None None 2016-03-08 08:38 EST
OpenStack gerrit 289920 None None None 2016-03-08 08:38 EST

  None (edit)
Description Chen 2016-03-07 02:14:22 EST
Description of problem:

Dashboard timezone is not valid by default

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

OSP 7.0

How reproducible:


Steps to Reproduce:
1. Change the TIME_ZONE to Asia/Tokyo in openstack-dashboard/local_settings 
2. Restart httpd service
3. Check the dashboard, the creation date of the instance is showed as Asia/Tokyo timezone.
4. Check Settings in dashboard, the timezone remains "UTC". If you click "Save" button, the creation date will revert back to UTC.

Actual results:

By default, if I don't click "Save" button, the creation date should remain "UTC" all the time even though I changed TIME_ZONE in local_settings

Expected results:

I have to click Save to make the dashboard settings enabled.

Additional info:
Comment 2 Matthias Runge 2016-03-08 08:38:05 EST
The time zone is stored in a cookie. If not set, it defaults to UTC.
Comment 5 Chen 2016-03-10 22:20:48 EST
Hi Matthias,

Thank you for your reply.

>the setting in local_settings should be taken into account. It defines a default time zone, but can be overridden by the logged in user.

Thank you for your explain. There is still one thing I can not understand. The expected behaviour of my understanding should be something like:

1. Change the local_settings TIME_ZONE from UTC to Asia/Tokyo
2. Check the dashboard settings, the timezone is still UTC (default).
3. The creation date of instances should remain UTC, because dashboard setting is UTC.

But now the creation date of instances changed to Asia/Tokyo unexpectedly. Only after clicking the "Save" button the creation date of instances will revert back to UTC. My thought is that the default setting of timezone in dashboard is not taken into account. 

>The timezone of horizon log should be unaffected by user changes. 

Hmmm, changing the TIME_ZONE option in local_settings could successfully change the timezone of the horizon.log.

Best Regards,
Comment 6 Chen 2016-03-28 03:27:03 EDT
Hi Matthias,

Would you please just let me know whether there is any bad impact if I change the TIME_ZONE in local_settings except the log and UI timezone changed ?

Best Regards,
Comment 8 Chen 2016-03-30 05:10:57 EDT
Hi Matthias,

Sorry I made things more confusing...

Here is the background and I hope this could make things clear.

At first my customer found that unlike other components (such nova, neutron and etc), horizon.log is recorded in "UTC" timezone and he just changed TIMEZONE option in local_settings.py (from UTC to Asia/Tokyo). That change met his expectation. (I'm not sure whether he wants to record the user activity but you know, sometimes the customers just hope one single component can act like others.) 

After that, he found that the timezone in WebUI was changed to Asia/Tokyo unexpectedly even though the WebUI timezone settings still shows "UTC". But if we click "Save" button the tiemzone in the WebUI will revert back to UTC. This made me think of that the WebUI was not taken into account until clicking the "Save" button. 

So here we have two places to set the timezone, one being local_settings.py and the other one being WebUI settings. Both are UTC by default and there is no conflict so far. The only problem here is, if I change the local_settings.py TIMEZONE option. Which configuration (local_settings.py or webUI settings) will decide the timezone on webUI ? My thought is that the webUI settings should do this job but it seems not according to #1.

The request still is: the timezone in webUI setting is not taken into account if I change TIMEZONE local_settings.py. 

Best Regards,
Comment 14 Beth Elwell 2016-11-30 11:59:19 EST
I believe this now to have been resolved as far as possible due to the merging of the patch addressing the default value and the secondary point relating to local browser cookies. As previously stated, we would advise that users need to clear their cookies on a TIME_ZONE change.

Note You need to log in before you can comment on or make changes to this bug.