[Lens] Time series XY - display current time range

[ghudgins]

Describe the feature: Display the date range of the visualization, including time zone.

Requirements:

• A configurable option to display time ranges (on for new visualizations?)
• Display of time zone information
• Integration with date format settings for the space (<-- should we use the field here? I don't think that makes sense)

Prototype screenshot:

Gold plating: also do the 1-bar = option at the same time! (probably a separate issue!)

Describe a specific use case for the feature:
It's just nice to have context
When I have an XY date histogram
I need an option to see the overall date range of the visualization
So I can have a very clear understanding of the range of data displayed

Downsampling causes time zone differences in one way or another
When I am reporting on data that involves downsampling
And Elasticsearch must downsample in a single time zone (UTC)
I need a way of seeing this distinction
So I can avoid confusion about either 1) days that start offset of my local time zones or 2) forced UTC and how that differs from Kibana's behavior today (<-- there may be more options here which will be discussed in another issue)

[elasticmachine]

Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors)

[ghudgins]

cc @elastic/datavis

[markov00]

I need an option to see the overall date range of the visualization

Do we have cases where we use allow the use of different time ranges on different time series in a dashboard?
If not, why do we need something different from the current time picker? Can we consider improving the display of time in the picker?

And Elasticsearch must downsample in a single time zone (UTC)
I need a way of seeing this distinction

With downsampling you can be in 3 situations:

1. show non-downsampled data
2. show only downsampled data
3. show half downsampled data and half non-downsampled one

In the 1) everything works as today.

In 2) we need to make clear to the user that we are using UTC instead of the configured timezone.

In 3) we need to make a choice: render each data point in its own timezone or convert to the common one that is UTC.
IMHO we should query everything in UTC, this reduces the cognitive load of understanding what is in UTC and what is in your local timezone and makes everything comparable.
This case is also the case of a dashboard where we have a chart using downsampled data and a chart using another index of non-downsampled data. It will be hard to compare aggregated days in UTC and aggregated days in UTC+5.
If it's clear to the user that we are switching to UTC for a specific reason (downsampling) they will understand and they can live with it easily.
A few more arguments for that:

• most timezones differ by multiple hours, this makes the conversion to UTC going unnoticeable in most cases (except for a minimal number of TZ that differs by 30 mins or 45 and 2 days a year where the DST changes the time), even we have 2 hours bucket and it doesn't start at the tip of the day, for most users doesn't create discomfort in reading the data trend.
• Daily, weekly, monthly downsampling are probably rare cases (I don't have arguments for that but we can consider reducing a year worth 1 billion documents into 356 aggregated documents is probably too much) and those are the only cases where converting a UTC day to a different timezone can result into shifted buckets (where the begin of the day may start 5 hours earlier), making it a bit more difficult to grasp (but not too hard).
• we should consider that situation 3) will appear just in one case: when a user is analyzing data between the end of a downsampled index and the beginning of a normal index. This case is probably less common than most use cases and can reach a user only when: the user is doing historical research on their data or the index was downsampled too early in the past (like just last week, or this morning, instead of considering downsampling for historical, less frequently used data).

With these considerations, I'm proposing to use just a single timezone for the overall dashboard (independently if we are showing data from a downsampled, non downsampled, mixed set of indices), and this timezone can be, probably, displayed together with the time picker, to keep the consistency with the time control we have at a dashboard level and across various chart editors.

[markov00]

In order to provide better transparency of priorities, issues that will not be prioritized within the next 24 months are being closed.

Tracking request in Lens general improvements ice box #184459