[Unified search] Manually changing the date in the timepicker in JP errors out

[stratoula]

Kibana version:
Possibly goes many versions back

Describe the bug:
If I work in kibana in JP and try to change the date manually then it reports the date as invalid while it shouldn't

Steps to reproduce:

1. Change kibana to ja-JP locale
2. Open the timepicker
3. Change the year from 2023 to 22
4. See that it marks it as invalid

Expected behavior:
It should accept these changes as it does in EN or FR locales

[elasticmachine]

Pinging @elastic/kibana-visualizations (Team:Visualizations)

[stratoula]

We added the locale in 8.10 so I have the feeling that this is an EUI bug. We need to confirm and create an issue to EUI.

[stratoula]

@elastic/eui-team We are using the SuperDatePicker and add the locale from i18n https://github.com/elastic/kibana/blob/main/src/plugins/unified_search/public/query_string_input/query_bar_top_row.tsx#L473

While the locale works fine and translates correctly when I try to change the time or date in the picker it errors out for some locales while it should not. I don't think I can fix it on the kibana side but can you confirm? 🙇‍♀️

[tkajtoch]

@stratoula I can't seem to reproduce it using just the EUI component with ja locale (see demo). I'll spin up a local kibana instance and see there.

Could you please confirm this issue appears in more places than just this one EuiSuperDatePicker usage?

[stratoula]

Could you please confirm this issue appears in more places than just this one EuiSuperDatePicker usage?

It appears everywhere we have this component in kibana. It is part of a reusable component called unified search so fixing it in one place will fix it everywhere.

The locales in kibana with the problem are:

• ja-JP
• zh-CN

[stratoula]

@cee-chen I am sending zh-cn which is correct locale and supported by moment. I have already checked that.
Btw it fails on your demo example too. Add zh-cn as locale change something, hit enter and see that it marks it as invalid

Here I changed the day from 8 to 7, hit enter and it is invalid. It should not, right?

[cee-chen]

Yes sorry, zh-cn of all cases is definitely supported by Moment, so that's really odd.

FWIW in your 2nd screenshot, the parent datepicker is showing as invalid because the date selected is after the 2nd date (now), but it should show as valid once you select a date before now (e.g. dec 6th). This is correct/expected behavior.

What's posted in the PR description is showing the absolute "Start date" input in the popover as having an invalid format, which is odd / I can't seem to reproduce that in the basic codesandbox.

[stratoula]

You are right 🤔 Honestly I am not sure what is going on. 🤷‍♀️

[cee-chen]

Ahh okay so this is really interesting. I tested on latest Kibana main with i18n.locale: zh-CN and was able to reproduce it (when editing the Start date input directly, but not when clicking dates in the calendar).

But the reason we can't reproduce it in CodeSandbox with latest EUI main is because we inadvertantly fixed this in elastic/eui#7331 and elastic/eui#7341 😆

Once the latest EUI upgrade lands in main (#170716 - it's taking a while because of some FTR/combobox shenanigans 🥲) it should theoretically be "just fixed" 🤞

[stratoula]

Aaaah thanx Cee, it was driving me crazy ❤️ I will keep it open and test again when the latest eui lands in kibana!

[stratoula]

As @cee-chen said, this is fixed after the latest eui upgrade.