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 "...
See more...
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.