Getting Data In

How to use relative dates based on now in a form's time picker?

twinspop
Influencer

The time picker field will use now as the latest time for many of the choices. I'm trying to create a week over week chart. The user selects "Last 4 hours", for example, and I create a chart with the last 4 hours plus the same 4 hours a week ago. I use $timepicker.earliest$-1w and $timepicker.latest$-1w for the previous week's numbers. However, now-1w coughs up an error.

Is there a way to make this work? Seems like an oversight since (all? most?) of the other relative time indicators work with the time arithmetic. Why is now treated differently?

Thanks!

Tags (3)
0 Karma
1 Solution

martin_mueller
SplunkTrust
SplunkTrust

You can work around that without having to rely on relative values from the timepicker at all - your approach breaks if someone selects a specific date and time, for example.

Here's a rough draft:

  base search earliest=$timepicker.earliest$ latest=$timepicker.latest$ | reporting stuff
| append [search base search
    [search index=* earliest=$timepicker.earliest$ latest=$timepicker.latest$ | head 1 | addinfo | eval earliest = relative_time(info_min_time, "-1w") | fields earliest]
    [search index=* earliest=$timepicker.earliest$ latest=$timepicker.latest$ | head 1 | addinfo | eval latest = relative_time(info_max_time, "-1w") | fields latest]
  | reporting stuff]

The two sub-subsearches load a dummy event, add the time range used as epoch values, do the subtraction of a week, and return the earliest and latest to the outer subsearch that then does the week-ago-search.
Adapt the things around the sub-subsearches to match whatever you're actually doing. Didn't test this, but it should work for everything you can select in the time range picker, including fixed dates or even all time - won't make sense for all time, but it won't throw up errors 😄

View solution in original post

martin_mueller
SplunkTrust
SplunkTrust

You can work around that without having to rely on relative values from the timepicker at all - your approach breaks if someone selects a specific date and time, for example.

Here's a rough draft:

  base search earliest=$timepicker.earliest$ latest=$timepicker.latest$ | reporting stuff
| append [search base search
    [search index=* earliest=$timepicker.earliest$ latest=$timepicker.latest$ | head 1 | addinfo | eval earliest = relative_time(info_min_time, "-1w") | fields earliest]
    [search index=* earliest=$timepicker.earliest$ latest=$timepicker.latest$ | head 1 | addinfo | eval latest = relative_time(info_max_time, "-1w") | fields latest]
  | reporting stuff]

The two sub-subsearches load a dummy event, add the time range used as epoch values, do the subtraction of a week, and return the earliest and latest to the outer subsearch that then does the week-ago-search.
Adapt the things around the sub-subsearches to match whatever you're actually doing. Didn't test this, but it should work for everything you can select in the time range picker, including fixed dates or even all time - won't make sense for all time, but it won't throw up errors 😄

*NEW* Splunk Love Promo!
Snag a $25 Visa Gift Card for Giving Your Review!

It's another Splunk Love Special! For a limited time, you can review one of our select Splunk products through Gartner Peer Insights and receive a $25 Visa gift card!

Review:





Or Learn More in Our Blog >>