We would like to know whether the event time is within working hours and a developer came up with the following. Does it make sense?
<base search>
| eval TimeZone=_time+" EST"
| eval eventTime=strftime(strptime(TimeZone,"%s.%Q %Z"),"%Y-%m-%dT%H:%M:%S.000%z")
| eval subtime=substr(TimeZone, 1, 10)
| eval date_wday=strftime(subtime,"%A")
| eval date_hour=strftime(subtime,"%k")
| search
date_wday IN ("Monday", "Tuesday", "Wednesday", "Thursday", "Friday") AND date_hour >= 7 AND date_hour < 18
Original text:
Sure, but you already have those fields (at least in 7.3) without doing any calculations
<base search> date_wday IN ("Monday", "Tuesday", "Wednesday", "Thursday", "Friday") date_hour >= 7 date_hour < 18
New answer:
See link provided by: @tsheets13, e.g.:
sourcetype=foo
| eval date_hour = strftime(_time, "%H"),
date_wday = strftime(_time, "%w")
| search date_hour>=7 date_hour<=18 date_wday>=1 date_wday<=5
Where date_wday of 1 is Monday and 5 is Friday.
Should work but a bit more complex than necessary. Look at this
https://answers.splunk.com/answers/371874/how-to-only-include-data-for-certain-hours-of-the.html
Original text:
Sure, but you already have those fields (at least in 7.3) without doing any calculations
<base search> date_wday IN ("Monday", "Tuesday", "Wednesday", "Thursday", "Friday") date_hour >= 7 date_hour < 18
New answer:
See link provided by: @tsheets13, e.g.:
sourcetype=foo
| eval date_hour = strftime(_time, "%H"),
date_wday = strftime(_time, "%w")
| search date_hour>=7 date_hour<=18 date_wday>=1 date_wday<=5
Where date_wday of 1 is Monday and 5 is Friday.
Weird thing as the date fields exist but with no values. What can it be?
It seems to be an old feature ... Is date_wday reliable to search on?
Apparently for Unix, the date fields are being populated but not for Windows.
We're in a full Windows environment. I've never had issues using them.
Either way, yes the search you provided makes sense. It's just much more work than should be necessary. We're on 7.24 by the way.
We are on 7.3, so I wonder what we are missing...
Looking at variance between time and date* fields1
@lguinn2 actually discourages us from using these date* fields.
Updated my answer. I agree with your comments.