Hello! Splunk n00b looking for confirmation of something! I can't find documentation for date_month that specifies whether it is localized. It appears that it isn't. Given this example search, which spans Feb 28 and Mar 1 in my timezone:
... earliest=1551384000 latest=1551416401 | eval date_month_local=strftime(_time, "%B") | search date_month=march date_month_local=February
Which returns results claiming to be in both March and February starting at 7pm local (I'm UTC-0500). That makes sense if date_month is based on UTC.*
Given that, if I have a report that I want to run on the previous month (Feb, in this example,) and I want a field with the name of the month in that report, should I be using strftime(time, "%B") instead of datemonth? If I use date_month, the report (which runs in -0500) ends up with a 'march' value for records after Feb 28 7pm -0500.
If I haven't completely missed something then all this might seem a bit self evident (and hopefully helpful for someone.) There was some surprise amongst management when it seemed that datemonth was not localized. That's why I want to be very sure I have this right. If anyone knows documentation that describes or implies how datemonth treats timezones, I would appreciate being pointed at it.
Thanks for your time!
*UPDATE: As described by somesoni2 in the accepted answer, date_month is based on the literal string at index time. In this case, the indexer was looking at a timestamp field which happened to be in UTC.
date_* fields are generated at index time and datetime values are the literal values parsed from the event when it is indexed, regardless of its timezone. So, the data might be generated, parsed and indexed on UTC time (check your indexer/heavy forwarder time zone) and then is translated to your timezone while searching. (See this for more information https://docs.splunk.com/Documentation/Splunk/7.2.4/Knowledge/Usedefaultfields#Default_datetime_field...)
The best way here would be to use _time based month calculation as that would honor your timezone/time range.
Just to clarify my own understanding, my assumption that datemonth is always based on UTC is not right? Instead, the value of datemonth is dependent on the indexer/heavy forwarder (which in this case appears to be set to UTC)?
Thanks again. I will look in to how to confirm the timezone configuration of our system.
date_* are parsed based on the literal value of the time fields, regardless of the time zone. So for date string 05:22:21 will be parsed into indexed fields: datehour::5 dateminute::22 date_second::21.
I'm not sure I understand what you mean by 'literal value of the time fields.' Are you talking about unix epoch time?
So if your raw data has timestamp as
2019-03-29 21:20:20 CST OR
2019-03-29 21:20:20 UTC, they both will have same date* field values. It's always going to take 21 as datehour, doesn't matter what the timezone is.