Skip to content
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

Merged
merged 9 commits into from
Aug 5, 2020

Conversation

asalem1
Copy link
Contributor

@asalem1 asalem1 commented Jul 29, 2020

Closes #17877

Problem

The problem with this was twofold:

  1. Toggling between timezones in the explorer (VEO / DE) was incorrectly adjusting times when timezones were East of GMT.
  2. Toggling between timezones on the dashboard page was not updating the timerange parameters to respect the timezone in dashboards
  3. Timerange selections with a timezone were not being respected in data visualization

Solution

The solutions to these issues were:

  1. Update the offset to be an absolute value rather than a negative, since that was incorrectly adjusting the times (and was leading to confusing assumptions)
  2. Updated the timerange being used for the cells (in the TimeSeries component) to account for timezone selections
  3. Updated the timeRange that was being passed to the Views (data visualizations) to respect the timezone selections
  • CHANGELOG.md updated with a link to the PR (not the Issue)

Copy link
Contributor

@hoorayimhelping hoorayimhelping left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -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')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.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 🤷

Copy link
Contributor Author

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

Copy link
Contributor

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:

  1. write a test that triggers the bug
    1. swap out your fix and code from master while writing the test if it helps writing the test
    2. confirm the test fails against master
  2. apply your fix and get passing tests reliably
  3. add your scary negative subtraction
  4. 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.

Copy link
Contributor Author

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

@asalem1
Copy link
Contributor Author

asalem1 commented Jul 30, 2020

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

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

.subtract(offset, 'minutes')
.format()
if (offset === 0) {
return moment.utc(date).format()
Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Contributor Author

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

Copy link
Contributor

@ebb-tide ebb-tide left a 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. :/

@asalem1 asalem1 force-pushed the timezone-offset-issue branch 2 times, most recently from 1362db0 to 975c732 Compare August 4, 2020 20:34
@asalem1
Copy link
Contributor Author

asalem1 commented Aug 4, 2020

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:

https://stackoverflow.com/a/15171030/7963795

Copy link
Contributor

@hoorayimhelping hoorayimhelping left a 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)
Copy link
Contributor

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)
Copy link
Contributor

@hoorayimhelping hoorayimhelping Aug 4, 2020

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
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You got it

@asalem1 asalem1 merged commit 2397f7f into master Aug 5, 2020
@asalem1 asalem1 deleted the timezone-offset-issue branch August 5, 2020 15:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

The UTC / Local dropdown does not work
3 participants