Bug 873795

Summary: PRD33 - Default time zone in New VM dialog
Product: Red Hat Enterprise Virtualization Manager Reporter: David Jaša <djasa>
Component: ovirt-engineAssignee: Martin Betak <mbetak>
Status: CLOSED ERRATA QA Contact: Jiri Belka <jbelka>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.1.0CC: 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
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 18:13:19 UTC
Miki, please advise

Comment 2 Miki Kenneth 2012-11-08 12:18:11 UTC
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 11:56:21 UTC
Agree that we should take the default timezone from the user browser.

Comment 4 Michal Skrivanek 2013-04-12 11:53:15 UTC
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 13:30:36 UTC
(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 22:55:17 UTC
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

Comment 9 Michal Skrivanek 2013-04-18 21:29:09 UTC
*** Bug 952350 has been marked as a duplicate of this bug. ***

Comment 10 Martin Betak 2013-04-19 10:01:14 UTC
(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 12:11:10 UTC
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-28 00:22:14 UTC
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 17:30:51 UTC
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