[UnifiedSearch] Relative date picker resets selection

[sukhwindersingh-qasource]

Describe the bug:
45 seconds are considered as 1 minute under relative set time.

Build Details:

VERSION: 8.5.0
BUILD: 56932
COMMIT: 1bb0d052c8d6842b88665c8c489f3a2d4cf4b46a

Preconditions

1. Kibana should be running.

Steps to Reproduce

1. Navigate to security in kibana.
2. Click on rules
3. Click on time shown at the right side of calendar icon and set seconds at 45s.

Actual Result
45 seconds are considered as 1 minute under relative set time.

Expected Result
60 seconds should be considered as 1 minute under relative set time.

Screen-Recording:

Alerts.-.Kibana.Mozilla.Firefox.2022-10-11.18-16-39.mp4

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[sukhwindersingh-qasource]

@karanbirsingh-qasource Please review this.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServicesSv)

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[elasticmachine]

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

[stratoula]

@sukhwindersingh-qasource I can't replicate it in Discover main
Also this component is an EUI component, the SuperDatePicker so this logic is not in kibana. I recommend:

• test it in latest main
• if this persists open the issue in EUI repo

I am removing the visualizations team's assignment

[markov00]

This is usually the way libraries like momentjs humanize a specific duration. You can test it also on momentjs docs page: https://momentjs.com/docs/#/durations/humanize/

They apply a generalization to that duration and this always be approximate, as you can see with 45 days => a month and so on.

I believe the ~ before the test is there to mean nearly a minute ago.
@stratoula @kertal I don't see the reason to use a humanized version of the relative time here, usually, this is used on blogs, and threads as the user doesn't care much about the precise time a post was submitted, but in our case, this probably could be more precise. Is also easier for us because we just use a single precise duration, that is already expressed in month/year/minutes/weeks, so a precise humanization doesn't create any issue.
Even if someone choose 120 seconds we don't need to humanize it to 2 minutes, but 120 seconds is good too.

[stratoula]

@markov00 I hear this, maybe we need to do these discussions with the EUI team which owns the component though. Kibana is just the consumer here.

[dej611]

In Kibana there's a special momentjs handler for this cases in https://github.com/elastic/kibana/blob/main/src/plugins/data/common/search/aggs/buckets/lib/time_buckets/calc_es_interval.ts#L85 which takes care to return "precise" human readable durations . Perhaps it can be outsourced to EUI?

[kertal]

FYI @elastic/eui-team

[stratoula]

In Kibana there's a special momentjs handler for this cases in https://github.com/elastic/kibana/blob/main/src/plugins/data/common/search/aggs/buckets/lib/time_buckets/calc_es_interval.ts#L85 which takes care to return "precise" human readable durations . Perhaps it can be outsourced to EUI?

Yes we are using it in aggregations, it could I guess y not, noone has complained about this afaik

[cee-chen]

EUI has a couple issues related to this:

• [EuiSuperDatePicker] Does not properly restore relative dates eui#4026
• [EuiSuperDatePicker] Auto-refresh button's pretty interval is too pretty eui#5752

The problem here is one of intention. It's a UX issue, not a developer one, and it's difficult to know what makes the most sense for all possible scenarios. The best we could likely do at the EUI level is add a doNotRound kind of prop/flag that developers can turn on on a case-by-case basis.

If that's something y'all want, please do feel free to leave a comment on elastic/eui#4026 requesting a reprioritization!