[Lens] Date formatter

[flash1293]

Based on #69820

Fixes #67206

This PR implements custom metric-level date formatters in Lens.

This changes make a bug in elastic-charts more noticable - duplicate tick labels are filtered out even if that doesn't make a lot of sense: elastic/elastic-charts#667

Data source state management

This PR slightly extends the FormattedIndexPatternColumn by adding a pattern: string attribute. As dates are all handled by the same formatter, this is enough to handle this extension - if a user specifies a custom format, it is stored as { id: 'date', pattern: '<selected pattern or custom pattern>'}. For the UI the pattern is mapped back to the named option.

Expression integration

The lens_format_column function is extended with a pattern argument passing the momentjs pattern through so it can be placed in the format hint.

[skip ci]

[flash1293]

@wylieconlon @mbondyra @AlonaNadler @cchaos This PR is not fully fleshed out yet, but the functionality should be there. I would like to collect feedback:

• Are the offered options the right ones?
• Should we change the labels?
• Pretty sure we should link to the docs of how to specify the pattern, I will add that later
• Is the implementation approach sound?

[AlonaNadler]

I think this issue is not a priority tbh. If we still go ahead and want to proceed with it I prefer we find a place where it doesn't show for every user using timestamp under some sort of an advance link. @cchaos maybe an advance link that opens another pop up? The reason is that options that are not used by most users or crucial shouldn't be displayed to avoid complexity. My concern that users will also confuse that with the interval, users who want to see monthy display will try to format instead of change the interval
The chart currently by default adjust the format based on the level of focus which is sufficient for most use cases.

[flash1293]

I see your point @AlonaNadler I just want to mention it would be cool if the place to put this is not the "Styling" tab because it's controlled by the Visualization (not by the data source controlling this format setting). A collapsed "advanced" UI seems like a good way.

[timroes]

I want to raise the concern here, about having users type moment.js patterns manually. We've seen high confusion about that in the past with numeral.js patterns in the number formatter, why we were planning to get rid of it there. I am not sure if we should allow the users to enter it here directly, or if we wouldn't be fine enough with a (long) list of reasonable defaults?

[wylieconlon]

@timroes As someone who has spent a significant amount of time trying to replace numeral formatting patterns, I understand why you are raising this concern. I was pretty convinced that Moment was implementing a standard set of date formatting tokens, but then I saw this comparison from the Moment docs which shows how messy it actually is. The only standardized representation in Javascript is Intl.DateTimeFormat, which will even be used by the upcoming Temporal type: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat

Based on this, I agree we should generate formats instead of allowing the user to type them.

[flash1293]

That comparison is really a gem, @wylieconlon :D Open to suggestions about what we should offer. A first idea is a kind of "builder" with switches for various parts, piecing together the full pattern:

• show year
• show month
• show day
• show hour
• show minute
• show second

[timroes]

That list is really gold. And yeah since they are diverging that strengthen the feeling, let's not have users enter it right now, since I think there's a realistic chance we want to use the vanilla API at some point :)

I'd suggest adding to your list @flash1293 an option whether to show 12h or 24h format. We've heard in the past more often that users would consider this to be easily configurable within an application and not as an "far away" setting somewhere.

[flash1293]

As there are still open questions and this feature is too low in the priority list right now, I'm going to close this PR for now and start from a recent state once it gets on roadmap again.