Description of problem: hi all, i meet a big problem about DWH Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hi, In order for me to help, Please provide full details about this issue. What is the environment? what rpm are installed? what is the problem exactly and how to reproduce. Thank you, Shirly
(In reply to Shirly Radco from comment #1) > Hi, > In order for me to help, Please provide full details about this issue. > What is the environment? what rpm are installed? what is the problem exactly > and how to reproduce. > > Thank you, > Shirly
It was found that for certain timezones there is an issue with the way the ETL interprets the timezone. Not ISO. e.g. China timezone. The error is during Hourly aggregation. # update history_configuration set var_datetime = 'Wed Dec 24 18:52:46 CST 2014' where var_name = 'lastHourAggr'; # select * from history_configuration ; var_name | var_value | var_datetime -------------------+-----------+------------------------ lastHourAggr | | 2014-12-25 08:52:46+08 Postgres thinks "CST" means US Central Standard Time (GMT-6, currently). If we want CST to mean China Standard Time, we will need to set up a We will need to output the time in an ISO format, like '2014-12-25 18:52:46+08', which removes all ambiguity.
*** Bug 1195395 has been marked as a duplicate of this bug. ***
Reopening because we plan to fix this issue in the ETL process.
zhangyaqi, Please do not close this. It was a bug and fixed. Waiting fot qa testing.
verified - ovirt-engine-dwh-3.6.0-0.0.master.20150617151108.20150617150804.gitfccbb7a.el6.noarch
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue. If problems still persist, please open a new BZ and reference this one.