Solved: Re: Why does TimePicker have old/lag context data ...

brunton2 · ‎04-15-2016

I'm trying to set readable tokens based on TimePicker entries but the token content retrieved and processed always seems to lag by one user input. Any suggestions/workarounds would be appreciated. Below is an example SimpleXML to reproduce the problem followed by example input/output:

<form autorun="true">
  <fieldset>
    <input type="time" token="timerange" searchWhenChanged="true">
      <label></label>
      <default>
        <earliest>0</earliest>
        <latest></latest>
      </default>
      <change>
          <eval token="et">strftime(relative_time(now(),'timerange.earliest'), "%m/%d/%Y %H:%M:%S")</eval> 
          <eval token="lt">strftime(relative_time(now(),'timerange.latest'), "%m/%d/%Y %H:%M:%S")</eval> 
      </change>
    </input>
  </fieldset>
      <row>
        <html>
            <p>Earliest: <b>$et$</b></p>
            <p>Latest: <b>$lt$</b></p>
        </html>
    </row>
</form>

Input 1:
7 Days Ago
Output 1: (Default is All Time)
Earliest: 12/31/1969 16:00:00
Latest: 04/15/2016 16:46:13

Input 2:
4 Hours Ago
Output 2: (Result of previous selection of 7 Days Ago, not 4 hours Ago)
Earliest: 04/08/2016 16:00:00
Latest: 04/15/2016 16:48:33

Input 3:
30 Days Ago
Output 3: (Result of previous selection of 4 Hours Ago, not 30 Days Ago
Earliest: 04/15/2016 12:50:00
Latest: 04/15/2016 16:50:15

martin_mueller · ‎04-15-2016

This happens because $timerange.earliest$ is set after the condition is evaluated, so you get the previous value. You're essentially referring to the result of the entire input while the result is still being computed.

Instead, use $earliest$ and $latest$ :

<change>
  <eval token="et">strftime(relative_time(now(),$earliest$), "%m/%d/%Y %H:%M:%S")</eval> 
  <eval token="lt">strftime(relative_time(now(),$latest$), "%m/%d/%Y %H:%M:%S")</eval> 
</change>

I fear this notion of "internal" and "external" tokens may not be entirely documented... yet.

View solution in original post

martin_mueller · ‎04-15-2016

This happens because $timerange.earliest$ is set after the condition is evaluated, so you get the previous value. You're essentially referring to the result of the entire input while the result is still being computed.

Instead, use $earliest$ and $latest$ :

<change>
  <eval token="et">strftime(relative_time(now(),$earliest$), "%m/%d/%Y %H:%M:%S")</eval> 
  <eval token="lt">strftime(relative_time(now(),$latest$), "%m/%d/%Y %H:%M:%S")</eval> 
</change>

I fear this notion of "internal" and "external" tokens may not be entirely documented... yet.

brunton2 · ‎04-15-2016

Tried that but it resulted in the tokens not updating at all. However it did trigger me to try the following which worked perfectly! Thanks so much for your quick and helpful reply, I've been bashing my head against a wall trying to get this working. I now can use this for transforming the timepicker selection for filter inputs to my dbquery (that I've also been trying to figure out for months)!

 <change>
   <eval token="et">strftime(relative_time(now(),'earliest'), "%m/%d/%Y %H:%M:%S")</eval> 
   <eval token="lt">strftime(relative_time(now(),'latest'), "%m/%d/%Y %H:%M:%S")</eval> 
 </change>

Why does TimePicker have old/lag context data during change event?

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Persistent Queue at TcpOut — One of Splunk's Most Practical Features

Skip the Awkward Silence: Have a .conf-ersation at .conf26

Rethinking Zero Trust: From Product Purchases to Logical Control Evidence

Join the Conversation