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

[twinspop]

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!

[martin_mueller · Accepted solution]

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 😄