-
Notifications
You must be signed in to change notification settings - Fork 122
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(xy): switch default timezone to local
#1544
fix(xy): switch default timezone to local
#1544
Conversation
BREAKING CHANGE: the default timezone is now the local browser timezone if not specified.
Do we need to backport this into a given kibana version? |
# [43.0.0](v42.1.0...v43.0.0) (2022-01-14) ### Bug Fixes * **heatmap:** labels visibility regression ([#1549](#1549)) ([067189d](067189d)) * **xy:** switch default timezone to `local` ([#1544](#1544)) ([1233e69](1233e69)) ### BREAKING CHANGES * **xy:** The time axis labels of a time-series chart configured without the timeZone prop are now rendering the labels with the local browser timezone instead of UTC.
@nickofthyme the triggering issue #122683 referenced 7.16.2+, worth double checking if it's the exact boundary of the refactoring PR impact, and likely backporting to restore the earlier behavior |
Yeah I don't see a |
@nickofthyme good call, and a question is, who we can/should reach out to about a fix release (7.16.4) cc @ghudgins @markov00 would be great to make a decision in proportion to the user impact |
@markov00 after discussing with Stratoula, I don't think it makes sense to backport elastic/kibana#121593 into Thoughts? |
@nickofthyme So before everything else we have this inconsistency:
Then on |
Yeah that's fine with me. So release |
The default timezone used when no timezone prop is provided is now aligned to the browser's local timezone. BREAKING CHANGE: The time axis labels of a time-series chart configured without the timeZone prop are now rendering the labels with the local browser timezone instead of UTC.
The default timezone used when no timezone prop is provided is now aligned to the browser's local timezone. These changes break the time axis labels of a time-series chart configured without the timeZone prop are now rendering the labels with the local browser timezone instead of UTC. Co-authored-by: Marco Vettorello <[email protected]>
Yes, I think if we can add the fix to 8.0 and 8.0.1 it will be perfect |
Sounds good but to be clear, I'm not adding this to |
Summary
The default
timezone
used when no timezone prop is provided is now aligned to the browser's local timezone.BREAKING CHANGE
The time axis labels of a time-series chart configured without the
timeZone
prop are now rendering the labels with the local browser timezone instead of UTC.Details
The PR #1383 correctly fixed our internal logic that uses the
UTC
timezone as the default timezone. The previous code unintentionally marked a not declared timezone asundefined
causing the usage of thetickFormatter
andniceTickFormatter
utility function to consider the timezone as the local browser's timezone.Before the mentioned PR, we where merging the timezones with the following code:
If no timeZone is specified the
timeZones
Set is empty and the call totimeZones.values().next().value
returnsundefined
that is, on the formatter, considered alocal
timezone.The PR instead changed the last code to:
where we always have a defined timeZone, that is always
UTC
when not specified.Reviewers
I've added but skipped two VRT tests: the function
page.emulateTimezone
is only available on an higher version of puppeteer, if I update puppeteer in this PR we will get a lot of vrt changes due to the updated chromium version. A subsequent PR will update puppeteer version and unskip the testsIssues
Solves elastic/kibana#122683 at the root, but as described in the comment the timezone should be specified manually on the props
Checklist
:xy
,:partition
):interactions
,:axis
)closes #123
,fixes #123
)dark
,light
,eui-dark
&eui-light