[Logs UI] timestamp visualization

[katrin-freihofner]

The timestamp in the current logs UI takes up a lot of horizontal space. As the date is highly repetitive the idea is to move the date in a separate row.

Additionally, I propose to have the date sticky in the table header.

[elasticmachine]

Pinging @elastic/infra-logs-ui

[Titch990]

Looks good to me. :-)

[tbragin]

@katrin-freihofner +1 on this idea.

[sgrodzicki]

Another idea would be to get rid of sub-second precision as the data is already sorted chronologically.

[weltenwort]

the data is already sorted chronologically

That is only true up to a precision of one millisecond. In larger setups there will be quite a few events per millisecond and the tendency is to go to nanosecond resolution as soon as the stack allows it.

[weltenwort]

Just a thought: Currently the date format is based on Kibana's advanced settings. If they will be split into separate date and time elements they will have to use a different source for that format.

[afgomez]

@weltenwort Do we happen to have data on how many people change that value? If there's a lot of people we can try to be smart about it and parse what value is in there.

For example with the default MMM D, YYYY @ HH:mm:ss.SSS value we could do something like:

• Split the string into characters.
• For each character:
  • if the character is not time formatting, add it to the date formatting, continue.
  • if the character is time formatting, add it and the rest of the string to the time formatting. End

Of course that is naive and it doesn't take into account certain scenarios, but it could be worth following that path

[jasonrhodes]

My opinion on the date format question, FWIW: I think it would be nice to "gently respect" a user's date time format choice, but more from a Sep 5, 2019 vs 5 Sep, 2019 vs 2019 Sep 5 perspective more than exactly the format they've chosen in settings. What I mean is that I don't think we should just blindly pull that format in if it doesn't work for the UX case and in this case not all formats will, because they're too bulky/noisy. But if someone has chosen day month and we are showing month day, that seems annoying.

Boiling down a format setting like this sounds complicated and I don't want it to hold up this feature. For now, I might either try to read in the current Kibana locale setting from config (config.get('i18n.locale')) and use it with toLocaleDateString()

new Date().toLocaleDateString('en-US', { month: 'short', year: 'numeric', day: 'numeric' })
"Oct 1, 2019"

If that ends up being too much of a pain, then just new Date().toLocaleString() might be the most user-friendly option ... although different from what @katrin-freihofner shows in the mockups:

new Date().toLocaleDateString()
"10/1/2019"

[katrin-freihofner]

Yes, that is a good point @jasonrhodes. I agree we should respect the date-time format choice a user made. The idea was more, whatever date format is, it should be the table header, while the time should be in the rows.

[afgomez]

@jasonrhodes something like https://github.com/elastic/kibana/blob/9bb2fc1739e340c8fdc9f9fe487bbca096ec641d/x-pack/legacy/plugins/infra/public/utils/formatters/datetime.ts

It's being used in the same PR https://github.com/elastic/kibana/pull/47042/files