fix(xy): switch default timezone to local

[markov00]

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 as undefined causing the usage of the tickFormatter and niceTickFormatter 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:

const timeZones = new Set<string>();
  specs.forEach((spec) => {
    if (spec.timeZone) {
      timeZones.add(spec.timeZone.toLowerCase());
    }
  });
const timeZone = timeZones.size > 1 ? 'utc' : timeZones.values().next().value;

If no timeZone is specified the timeZones Set is empty and the call to timeZones.values().next().value returns undefined that is, on the formatter, considered a local timezone.

The PR instead changed the last code to:

const timeZone = timeZones.size === 1 ? timeZones.values().next().value : 'utc';

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 tests

Issues

Solves elastic/kibana#122683 at the root, but as described in the comment the timezone should be specified manually on the props

Checklist

• The proper chart type label has been added (e.g. :xy, :partition)
• The proper feature labels have been added (e.g. :interactions, :axis)
• All related issues have been linked (i.e. closes #123, fixes #123)
• Unit tests have been added or updated to match the most common scenarios
• The proper documentation and/or storybook story has been added or updated
• The code has been checked for cross-browser compatibility (Chrome, Firefox, Safari, Edge)
• Visual changes have been tested with all available themes including dark, light, eui-dark & eui-light

[nickofthyme]

Do we need to backport this into a given kibana version?

[monfera]

@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

[nickofthyme]

Yeah I don't see a 7.16.4 scheduled so my guess is we just backport into 7.17 for now, agreed?

[monfera]

@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

[nickofthyme]

@markov00 after discussing with Stratoula, I don't think it makes sense to backport elastic/kibana#121593 into 7.17 nor 8.0. That said I don't know where to put this fix because if we add it to 7.17 it won't be in 8.0 which would be weird and hence the whole issue we’ve been facing with this late minor. Also 7.17 is on elastic/charts@40.2.0 and this change is technically breaking and we already have a 41 version.

Thoughts?

[markov00]

@nickofthyme So before everything else we have this inconsistency:

• 7.17 is on 40.2.0 commits
• 8.0 is on 40.1.1 commits
  I think we should align 8.0 to 40.2.0 so we have also the waffle fix

Then on 40.2.0 we should backport this fix without the breaking change flag. I know that semantically is not correct but we can't do otherwise. This fix needs to land on Kibana 7.17 and 8.0 we can't do otherwise. WDYT?
In the meantime, Infra team have patched 7.16, 7.17, 8.0 and 8.x with elastic/kibana#123139

[nickofthyme]

Yeah that's fine with me. So release 40.3.0 with the fix and add it to 7.17 and 8.0 (i.e. 8.0.1)?

[nickofthyme]

@monfera & @markov00 See elastic/kibana#123264 & elastic/kibana#123265

[markov00]

Yes, I think if we can add the fix to 8.0 and 8.0.1 it will be perfect

[nickofthyme]

Sounds good but to be clear, I'm not adding this to 8.0.