X-Axis doesn't respect timepicker for date histograms, + other oddities

[ebalmeida]

Kibana version:
v 6.4.1
Elasticsearch version:
v 6.4.1
Server OS version:
CentOS 7.5
Browser version:
Chrome 71.0.3578.98
Browser OS version:
Windows 10 - 1809
Original install method (e.g. download page, yum, from source, etc.):
tar
Describe the bug:
When I set the interval to monthly or yearly on a date histogram (vertical bar) visualization, the x-axis seems to ignore limits set in the timepicker and the labels behave erratically (labels don't respect the "filter labels" option, labels repeat if not enough buckets are present).
Took suggestion to post it as an issue as per: https://discuss.elastic.co/t/x-axis-labels-and-limits-on-date-histogram-based-on-the-interval/167020
Steps to reproduce:

1. Create a date histogram based on a date value
2. Set the interval manually
3. Change time span on the time picker

Expected behavior:
X-axis should be limited by whathever was stipulated on the timepicker.
Labels should all show up if "filter labels" is not selected.
Labels should not repeat if there is a small number of buckets.

Additionally, if the chart style is bar, it would make more visual sense if the time label is centered on the bucket instead of coming before the bucket.
Screenshots (if relevant):

[elasticmachine]

Pinging @elastic/kibana-app

[markov00]

hey @flash1293 do you think this is somehow related to this #32252

[flash1293]

Thanks a lot for reporting, @ebalmeida !

The part about

Additionally, if the chart style is bar, it would make more visual sense if the time label is centered on the bucket instead of coming before the bucket.

might be caused by this, but I'm not 100% sure.

The thing with filter labels is definitely a bug, probably related to data binding. It seems like initially the value in the state is undefined which is somehow treated as true - if you select and deselect the checkbox, it works as expected (see gif). I'm going to prepare a PR for that, but I'm we will not backport this till 6.4.

Also unsure about the repeated labels - are we sure this isn't just expected behavior? @timroes do you know this by any chance?

[ebalmeida]

Thank you very much for looking into it.

I ended up circumventing the original problem by pretty much not relying on the time picker anymore.
I have update those instances to 6.6 docker btw, and will soon be running them in a 7.1.1 cluster so backporting won't be an issue (at least for me)

The part about <...> might be caused by this, but I'm not 100% sure.

I'm not sure if the "this" you're referring to is the filter labels 'bug'. If it is, unclicking, running and clicking once again doesn't really change the label behaviour. I think it's more the case of working as designed... I wonder if it should though, since every user I introduce to it find this behaviour odd. Excel has 'taught' us that bar labels go below the bar, centered.

Also unsure about the repeated labels - are we sure this isn't just expected behavior? @timroes do you know this by any chance?

I guess the same kind of thinking goes here. Even if it's WAD should it really be that way? I mean, it doesn't look nice and I don't believe it adds any relevant information.

[flash1293]

I'm not sure if the "this" you're referring to is the filter labels 'bug'.

Ah sorry, I was referring to the issue @markov00 linked above.

I agree with you that the repeated and uncentered labels are not the right behavior for bar charts, let me branch this out in a separate issue and track just the bug with filtered labels here in this issue.

[ebalmeida]

Ah sorry, I was referring to the issue @markov00 linked above.

Of course, silly me!

Thanks a million. Please @ me in the new issue =)

[flash1293]

Probably related issue to the "Filter labels" bug: #21589

[flash1293]

@ebalmeida Follow up question about the other problem with the range from the time picker not being applied to the chart at all: Could you please confirm that the field the date_histogram aggregation is applied to (DATA_ENCERRAMENTO) is also the field configured as "Time Filter field name" in index pattern management for the processos* index pattern? The time picker on the top right always refers to this field, not to the field currently used on the x axis.

[ebalmeida]

Well, unfortunatelly I can no longer answer that one since we have reindexed that data and rebuilt the visualizations around the problem since I posted the issue. I think we can assume it was and that was the problem since we usually used another field as the index's time field.

A little context (although not directly related to the issue at hand):
The whole single time picker issue is proving to be an issue though, since our users usually want to filter by several date ranges (start dates, end dates, confirmation dates, etc.) at once. The only way I found to do that (apart from doing manual filters, of course) is "casting" the dates to a numeric value (for instance, scripting a field that shows how long ago in months was an end date) and then using a range filter control visualization. Nowadays I basically don't even use an index time field anymore since I found that it usually confuses the user as to what date they are filtering by in the time picker (they usually think that the filter should apply to every and any chart, for instance, if it's a chart by start date it should filter by that, but if it's by end date it should do that - of course I see how that's not feasible)

[flash1293]

@timroes Do we already have an issue for the feature request above (Having time ranges on multiple time fields)?

[flash1293]

X-axis should be limited by whathever was stipulated on the timepicker.

See #30138 (comment)
@ebalmeida Could you open a separate feature request about ticker pickers for multiple fields?

Labels should all show up if "filter labels" is not selected.

#38644

Labels should not repeat if there is a small number of buckets.
Additionally, if the chart style is bar, it would make more visual sense if the time label is centered on the bucket instead of coming before the bucket.

#38494

Closing this issue as the reported bug has been addressed, other things should be moved to separate issues