-
Notifications
You must be signed in to change notification settings - Fork 898
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove conversion to UTC in Chargeback #17606
Remove conversion to UTC in Chargeback #17606
Conversation
@lpichler Can you write a test for this? Also, could you summarize the problem and why we're removing the UTC conversion in the PR description and commit message? It's unclear why this was done by just looking at the commit/PR. From what I'm understanding, it's something like this: "Because we expect resources to be charged for their usage in their local time, we must remove UTC conversion for the report data range to ensure the range starts and ends in local time to avoid incorrect results such as double costs for one month and no charge for the next month" |
@@ -62,14 +62,14 @@ def report_time_range | |||
ts = Time.now.in_time_zone(tz) | |||
case interval | |||
when 'daily' | |||
start_time = (ts - start_interval_offset.days).beginning_of_day.utc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to put a comment above ts = Time.now.in_time_zone(tz)
saying something like # Use local time for determining the start and end of the date range since we use and are charged for consumption in local time
. Or something that clearly states why we're using local time here.
@jrafanie it is described here #13398 because we caught it in past time and there is just different time zone used. It is pretty edge case. Look on it and let me if it brings light to you. I did not finish it because it was never ending story to write test for in CI environment for me but there is test and it us briefly describing it in comment in code. Briefly. Let me know if it is more understandable. thanks |
The effect of this is that the report is picking up the last day of April in addition to the entire month of May when the report should just be for May. This is what's happening in the code -
|
@miq-bot add_label blocker |
@lpichler if this can be backported, can you add the gaprindashvili/yes label. |
@miq-bot add_label gaprindashvili/yes |
@lpichler Document it once in the commit message for future everyone. Looking at this commit/change 6 months from now, I have no idea why we're using local time here. Make your commits clear as to why you're making a change. It's automatically used in the description of the PR (if single commit). The commit message(s) get auto-copied to the BZ on merge so there's no need for you to describe it any further. |
Conversion to UTC is superfluous here. We are splitting out time base according to report interval - daily,weekly and monthly. Reference date is Time.now (includes local time) and we are converting this date to zone from report definition and we are determining beginning of report interval. After this we were converting the beginning of month to UTC which was considered as improper step. it is improper because it can end in previous month and then interval is split out badly Example: Time.now: 2018-06-20 09:33:38 +0200 in report zone ("Seoul" +0900): Wed, 20 Jun 2018 16:34:24 KST +09:00 beginning of month (we are consider 1 month back): Tue, 01 May 2018 00:00:00 KST +09:00 ^ this ok but when we convert it to utc: 2018-04-30 15:00:00 UTC as you can it ends in different month and this date is user to querying on metric rollup and then we are getting different set of metric rollups.
d61ac8a
to
9dc1e1c
Compare
@jrafanie @gtanzillo I described issue in commit message 👍 |
Checked commit lpichler@9dc1e1c with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
I will add test in follow up PR. |
@lpichler next time, please put the bz link in the commit message so the commit message will be automatically copied to the BZ (and you don't have to explain what you did again in the bz) |
…port_interval_in_chargeback Remove conversion to UTC in Chargeback (cherry picked from commit 9fe07d0) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1593678
Fine backport details:
|
…port_interval_in_chargeback Remove conversion to UTC in Chargeback (cherry picked from commit 9fe07d0) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1593677
Gaprindashvili backport details:
|
pulled out from #13398
description is in ^
currently it is tricky to cover it by tests because of zone setting in CI.
cc @jrafanie @gtanzillo
Links
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1587857