I made a graph that send time data at click point.
I use "fieldformat" to change time data shown.
This is my code about time part at this graph.
| rename _time AS Date
| fieldformat Date = strftime(Date,"%Y-%m-%d")
So the token data send like this "2024-01-23"
I want to set the time with the data received from the token about another graph.
For example, If time_token send me "2024-01-23", I want to show only the data from 2024-01-23 in another graph.
I tried this code, but it not worked. (Maybe it cause about format changing)
| where _time = time_token
How could I solve this problem?
First, surround the token name with dollar signs, i.e., $time_token$. Second, if _time in your second search is Splunk's built in event time, its value is epoch, and will never equal a string like "2024-01-23". Third, when you rename _time in the first search to Date then use fieldformat on this field, you are only changing the display. $time_token$ transmitted to the second search is still the original _time value, which is NOT the date value, but the precise event value in the first search. As such, chances are extremely slim that the second search will find a match.
You need to rethink what value to send to the second search. The solution depends very much on what are you doing with Date field in the first search and what exact value you are trying to match in the second search. No one else knows those conditions but yourself. So, you will need to describe them very clearly.
I will give you one example. Suppose _time in your second search is event time, Date in the first search is just for display, and that you want to match calendar date between the first and second searches, even though the events' time of day is different. (These are big IFs. Like I said, no one else knows what your use case is and how data look like.) In this case, you can keep the first search, and work on the second search to match calendar date like this:
| where relative_time(_time, "-0d@d") == relative_time($time_token$, "-0d@d")
This is perhaps the most expressive way to implement the use case I exemplified above, although it is not the most semantic in accordance to your original design. If you want to be semantical, both the first search and second search need a change.
First, surround the token name with dollar signs, i.e., $time_token$. Second, if _time in your second search is Splunk's built in event time, its value is epoch, and will never equal a string like "2024-01-23". Third, when you rename _time in the first search to Date then use fieldformat on this field, you are only changing the display. $time_token$ transmitted to the second search is still the original _time value, which is NOT the date value, but the precise event value in the first search. As such, chances are extremely slim that the second search will find a match.
You need to rethink what value to send to the second search. The solution depends very much on what are you doing with Date field in the first search and what exact value you are trying to match in the second search. No one else knows those conditions but yourself. So, you will need to describe them very clearly.
I will give you one example. Suppose _time in your second search is event time, Date in the first search is just for display, and that you want to match calendar date between the first and second searches, even though the events' time of day is different. (These are big IFs. Like I said, no one else knows what your use case is and how data look like.) In this case, you can keep the first search, and work on the second search to match calendar date like this:
| where relative_time(_time, "-0d@d") == relative_time($time_token$, "-0d@d")
This is perhaps the most expressive way to implement the use case I exemplified above, although it is not the most semantic in accordance to your original design. If you want to be semantical, both the first search and second search need a change.
Hello @yuanliu
What you wrote is similar to my situation.
I solve this problem using different way (Notice that this wasn't the way to go).
But your answer made me aware of factors to think about.
Thank you for your helping!
| where _time = strptime(time_token,"%Y-%m-%d")