Bug 873795 - PRD33 - Default time zone in New VM dialog
PRD33 - Default time zone in New VM dialog
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.3.0
Assigned To: Martin Betak
Jiri Belka
virt
: Improvement, ZStream
: 952350 (view as bug list)
Depends On:
Blocks: 972739
  Show dependency treegraph
 
Reported: 2012-11-06 12:57 EST by David Jaša
Modified: 2015-09-22 09 EDT (History)
17 users (show)

See Also:
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 12:30:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
oVirt gerrit 14248 None None None Never

  None (edit)
Description David Jaša 2012-11-06 12:57:14 EST
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

How reproducible:
always

Steps to Reproduce:
1. open a "create a new VM" dialog, ot to "Initial run" tab
2.
3.
  
Actual results:
tz is set to UTC-12

Expected results:
tz should match that of RHEV-M (or better: it should match user time zone)

Additional info:
this should be default behaviour for restapi when tz is not specified in any way even when bug 633675 gets implemented
Comment 1 Barak 2012-11-06 13:13:19 EST
Miki, please advise
Comment 2 Miki Kenneth 2012-11-08 07:18:11 EST
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.
Comment 3 Andrew Cathrow 2012-12-03 06:56:21 EST
Agree that we should take the default timezone from the user browser.
Comment 4 Michal Skrivanek 2013-04-12 07:53:15 EDT
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.
Comment 5 David Jaša 2013-04-12 09:30:36 EDT
(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.
Comment 6 Itamar Heim 2013-04-16 18:55:17 EDT
this may be relevant:

commit da2e04242d5d7bae0e0905f20e64fe1bebfde219
Author: Arik Hadas <ahadas@redhat.com>
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
Comment 9 Michal Skrivanek 2013-04-18 17:29:09 EDT
*** Bug 952350 has been marked as a duplicate of this bug. ***
Comment 10 Martin Betak 2013-04-19 06:01:14 EDT
(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
Comment 15 Jiri Belka 2013-06-26 08:11:10 EDT
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)
Comment 16 Charlie 2013-11-27 19:22:14 EST
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.
Comment 18 errata-xmlrpc 2014-01-21 12:30:51 EST
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

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