-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
fix(dashboard-timezone-selection): toggling timezone should update queries timerange to respect timezone selection #19146
Conversation
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.
how about adding some test cases for this bug and its fix: https://github.com/influxdata/influxdb/blob/master/ui/src/dashboards/selectors/index.test.ts
ui/src/dashboards/selectors/index.ts
Outdated
@@ -59,7 +59,7 @@ export const setTimeToUTC = (date: string): string => { | |||
if (offset < 0) { | |||
return moment | |||
.utc(date) | |||
.add(offset, 'minutes') | |||
.add(Math.abs(offset), 'minutes') |
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.
.add(Math.abs(offset), 'minutes') | |
.subtract(offset, 'minutes') |
seems odd to me to explicitly check for a negative number, then take the absolute value of it 🤷
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.
@hoorayimhelping I hear what you're saying and it's something I considered but wasn't bold enough to try. Let me give it a shot and see if it has the same outcome
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.
@asalem1 here's a method i've used in the past to gain confidence:
- write a test that triggers the bug
- swap out your fix and code from master while writing the test if it helps writing the test
- confirm the test fails against master
- apply your fix and get passing tests reliably
- add your scary negative subtraction
- if tests pass, confidence. if tests fail, put it back the way it works 👍
this works because you go through the steps of triggering the bug against master, then fixing it. that is what gives you the confidence in your solutions and your tests.
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.
Totally a great idea, unfortunately testing relative time based on a timerange here is not as straightforward as it seems due to the constraints of our current testing framework
Definitely hear where you're coming from but am a little a loss on how to add some tests for stability here, since it would require mocking out date locales in order to ensure that this feature works across different timezones (which is something that we weren't able to do originally). If you'll recall from the previous PR that's related to this issue, this wasn't actually possible due to configuration variables that cannot be manipulated within out current testing framework |
ui/src/dashboards/selectors/index.ts
Outdated
.subtract(offset, 'minutes') | ||
.format() | ||
if (offset === 0) { | ||
return moment.utc(date).format() |
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.
Is this needed? if offset = 0, would .subtract(offset, 'minutes')
not just return zero? I don't know the answer just thought I'd check
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.
That's a great question / point. I think I had originally implemented this so that it wouldn't overwrite formatted data unnecessarily. Let me just check real quick to see if it makes a difference
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.
Great point, totally didn't consider this. You're 100% correct
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.
It's tricky that you can't test in different time zones. :/
1362db0
to
975c732
Compare
The most recent PR addresses some of the limitations that the previous testing suite could not. In order to do so, I had to mock out the getTimezoneOffset functionality for testing purposes. This decision was made after making attempts to mock out the Date object's timezone reference within the test suite itself. However, this proved to be an unlikely path. The most compelling argument I found can be seen here: |
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.
good work on those tests
@@ -118,6 +136,70 @@ describe('Dashboards.Selector', () => { | |||
type: 'custom', | |||
} | |||
|
|||
mocked(getTimezoneOffset).mockImplementation(() => 420) |
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.
can you add a comment here saying this is the value returned for california in daylight savings time?
actually ignore the above, it's subtly wrong. this is the value returned for -7 UTC timezone, which is the timezone california is in during daylight savings time. in the winter time, this will be 360.
type: 'custom', | ||
} | ||
|
||
mocked(getTimezoneOffset).mockImplementation(() => -120) |
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.
same thing here about adding a comment for whichever timezone is +2 utc
@@ -0,0 +1,14 @@ | |||
/** | |||
* PLEASE READ |
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.
suggestion: ✂️ the 'please read' part
a big comment implies it should be read. 'please read' almost comes off like the comment is begging for attention, like pls respond
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.
You got it
7098d6d
to
33bb672
Compare
…ment Still need to address dashboards refreshing when toggling timezones
…ce it no longer makes a difference
33bb672
to
5dedd66
Compare
Closes #17877
Problem
The problem with this was twofold:
Solution
The solutions to these issues were: