Red Hat Bugzilla – Bug 873795
PRD33 - Default time zone in New VM dialog
Last modified: 2015-09-22 09:09 EDT
Description of problem:
default time zone for VMs should match RHEV-M timezone (or better: users time zone as requested in bug 633675). UTC-12 isn't exactly the best default
Version-Release number of selected component (if applicable):
si24 / 3.1.0-26.el6ev
Steps to Reproduce:
1. open a "create a new VM" dialog, ot to "Initial run" tab
tz is set to UTC-12
tz should match that of RHEV-M (or better: it should match user time zone)
this should be default behaviour for restapi when tz is not specified in any way even when bug 633675 gets implemented
Miki, please advise
The current behaviour should be changed.
I'm debating with my self what should be the default behaviour:
- RHEV-M time zone
- User Time Zone.
I would vote for the User TZ, but I really thing we need a way to configure the default value.
Agree that we should take the default timezone from the user browser.
still some trouble is it's not matching exactly. We can get the GMT offset, but not the exact name of the TZ. There are many which differ only in name. So it can only be a guess(and it will be a wrong one, e.g. for Brno TZ it would pick West Africa Time as it is first one among all GMT+01 TZs)
I believe we need default in engine-config as an override in any case.
(In reply to comment #4)
> still some trouble is it's not matching exactly. We can get the GMT offset,
> but not the exact name of the TZ.
There are hacks available such as:
or guess the zone from offset + capital letters in parentheses in <date>.toString().
> I believe we need default in engine-config as an override in any case.
That could be easily the engine locale, and an item to set in rhevm-setup/answer file as well.
this may be relevant:
Author: Arik Hadas <firstname.lastname@example.org>
Date: Tue Mar 19 18:48:08 2013 +0200
frontend: add an option of default timezone
This patch adds an empty entry in the timezones list presented in the
UI, which represents the selection of the default timezone that is
defined in the system.
This new empty entry is now selected by default when creating new VM,
and when editing a VM that no timezone was defined for it.
This patch fix bug 922609: before this patch the first timezone was
selected by default when opening the edit dialog of VM with no timezone
defined and therefore when pressing 'ok' the system detected a change in
the timezone field and tried to update it - even when it wasn't possible.
from now on, the empty entry will be selected by default in that case so
no change will be detected unless the user actually changed the timezone
*** Bug 952350 has been marked as a duplicate of this bug. ***
(In reply to comment #5)
> (In reply to comment #4)
> > still some trouble is it's not matching exactly. We can get the GMT offset,
> > but not the exact name of the TZ.
> There are hacks available such as:
> or guess the zone from offset + capital letters in parentheses in
> > I believe we need default in engine-config as an override in any case.
> That could be easily the engine locale, and an item to set in
> rhevm-setup/answer file as well.
Yes I looked into jstimezonedetect but it is too simplistic - it doesn't take into account Daylight savings time for example and just guesses your location from the offset, for example this time of year in Brno it returned Europe/Berlin so I doubt how much helpful would this be for the user. Not to mention that windows sysprep uses completely different set of (format of) timezones than those returned by jstimezonedetect. That is why we cannot do simple translation from offset -> valid sysprep value even though getting the offset itself is trivial (new Date().getTimezoneOffset()).
for example to offset +4 correspond both:
(GMT+04:00) Arabian Standard Time and
(GMT+04:00) Georgian Standard Time
merged to master:
[root@jb-rh33 ~]# psql -U engine
Password for user engine:
Type "help" for help.
engine=> select * from vdc_options where option_name like '%TimeZone%';
option_id | option_name | option_value | version
390 | DefaultWindowsTimeZone | GMT Standard Time | general
391 | DefaultGeneralTimeZone | Etc/GMT | general
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.
Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:
* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')
Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.
For further details on the Cause, Consequence, Fix, Result format please refer to:
Thanks in advance.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.