Timefilter API weirdness and inconsistencies

[JacobBrandt]

Kibana version:
6.6

Describe the bug:
The behavior of the API and it's values is not consistent.

On Discover page there is this method:

$scope.updateTime = function () {
  $scope.timeRange = {
    from: dateMath.parse(timefilter.getTime().from),
    to: dateMath.parse(timefilter.getTime().to, { roundUp: true })
  }
}

When 'This week' is selected on the Discover page as a time range the timefilter.getTime().from/to values are moment objects. Thus one would look at this method and say ok this is how I parse time filters for my own visualizations time ranges. However, on a dashboard when 'This week' is selected as a time range the from and to values are the same value and are NOT a moment object but a string "now/w". Thus the calculation doesn't work because from and to are the same value for some odd reason.

This kind of inconsistency is really disturbing. How is someone suppose to know that the same time range state does not return the same values from timefilter (in this case not even the same type of object for the value) depending on the page you are on.

The next issue is with the API. from/to are suppose to represent a range. However, on a dashboard they have the exact same value when the time selected is 'This week'. Thus the API itself is returning inconsistent values when it is in this state.

Time range state on a dashboard: This week
timefilter.getTime().from/to: Will both be now/w. Thus representing a single point in time
timefilter.getBounds().min/max : Will be two different moment objects whose range is a week

Expected behavior:
I would expect that the time range I select on pages would be represented in the timefilter values the same on all pages and not sometimes a string and sometimes a moment object for the exact same time range.

I also would expect know matter which part of the API is called to provide the same information.

[flash1293]

Hi @JacobBrandt, thanks for reaching out.

First a quick question to make sure - did you mean version 7.6? 6.6 is pretty old and we won't do changes there anymore.

When 'This week' is selected on the Discover page as a time range the timefilter.getTime().from/to values are moment objects

That's not the case - getTime() will either return a iso-encoded date in a string or a datemath expression:

kibana/src/plugins/data/public/query/timefilter/timefilter.ts

Line 92 in 58d5688

public getTime = (): TimeRange => {

Maybe you confused it with the return value of dateMath.parse(timefilter.getTime().from)? the datemath library will always return moment objects.

This kind of inconsistency is really disturbing. How is someone suppose to know that the same time range state does not return the same values from timefilter (in this case not even the same type of object for the value) depending on the page you are on.

Individual apps have their own internal logic of handling their state and they are not guaranteed to be 100% consistent. The "source of truth" here is the timefilter service of the data plugin - it will always contain either an iso-date string (if the user selected an absolute date in the time picker) or a date math expression when the user selected a range like "This week". One important note: When interpreting the values of from and to as datemath, the to value is rounded up, while the from value is rounded down.

timefilter.getTime().from/to: Will both be now/w. Thus representing a single point in time

That's not the case - (see the reasoning above) - (the roundUp: true option in the second parse call causes this)

I would expect that the time range I select on pages would be represented in the timefilter values the same on all pages and not sometimes a string and sometimes a moment object for the exact same time range.

When calling getTime(), this is made consistent - either an iso-date string or a date math expression. If you just want the range, you can use getBounds() - this API is meant to be used when building an ES query.

The way the individual apps work is not guaranteed to be consistent.

I also would expect know matter which part of the API is called to provide the same information.

Always query the timefilter, it will contain the right value in a consistent way. If you just care about building queries, the getBounds() method is probably what you are looking for and will always give you a moment object of the currently selected time range.

I hope that helped somehow, let me know if you have further questions.

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[JacobBrandt]

I did mean 6.6. I should have looked at what I was seeing more closely. It's never a moment object like I thought. However, I still am correct that:

timefilter.getTime().from/to: Will both be now/w. Thus representing a single point in time

That's not the case - (see the reasoning above) - (the roundUp: true option in the second parse call causes this)

It actually is the case. The roundUp option is not something you provide to timefilter. So timefilter .getTime().from/to are indeed returning this: {from: "now/w", to: "now/w", mode: "quick"} by itself which does mean the from value is the same as to which by itself is saying there is no range.

If you just want the range, you can use getBounds() - this API is meant to be used when building an ES query.

Yep found that out and that's exactly my point of this ticket.

Thus the API itself is returning inconsistent values when it is in this state.

Time range state on a dashboard: This week
timefilter.getTime().from/to: Will both be now/w. Thus representing a single point in time
timefilter.getBounds().min/max : Will be two different moment objects whose range is a week

If you want the range and are not using the datemath library and only using the timefilter object don't use timefilter.getTime().from/to because those values don't always give you a range.