Bug 873795
Summary: | PRD33 - Default time zone in New VM dialog | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | David Jaša <djasa> | |
Component: | ovirt-engine | Assignee: | Martin Betak <mbetak> | |
Status: | CLOSED ERRATA | QA Contact: | Jiri Belka <jbelka> | |
Severity: | medium | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 3.1.0 | CC: | aburden, acathrow, adahms, bazulay, cpelland, iheim, jkt, lpeer, lyarwood, mbetak, michal.skrivanek, mkenneth, pmukhedk, pstehlik, Rhev-m-bugs, rhodain, yeylon | |
Target Milestone: | --- | Keywords: | Improvement, ZStream | |
Target Release: | 3.3.0 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | virt | |||
Fixed In Version: | is1 | Doc Type: | Enhancement | |
Doc Text: |
With this feature, the Edit Virtual Machine window now uses the default time zone specified in engine-config. The default time zone used in the window corresponds to the DefaultWindowsTimeZone key for Windows-based virtual machines and the DefaultGeneralTimeZone key for all other virtual machines.
|
Story Points: | --- | |
Clone Of: | ||||
: | 972739 (view as bug list) | Environment: | ||
Last Closed: | 2014-01-21 17:30:51 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 972739 |
Description
David Jaša
2012-11-06 17:57:14 UTC
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: http://cdnjs.com/#jstimezonedetect 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: commit da2e04242d5d7bae0e0905f20e64fe1bebfde219 Author: Arik Hadas <ahadas> 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 field. Change-Id: I7f8c80ae783e88740ee907d9ff52c0bd6c40734c Bug-Url: https://bugzilla.redhat.com/922609 *** 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: > http://cdnjs.com/#jstimezonedetect > > 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. 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: http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=6fa3626ddee0c3f2716d99a69ba4f3ff1057e838 OK, ic2. [root@jb-rh33 ~]# psql -U engine Password for user engine: psql (8.4.13) 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 (2 rows) 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: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 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. http://rhn.redhat.com/errata/RHSA-2014-0038.html |