Hello,
I have a timezone issue that I don't understand.
I have two set of indexed logs in different indexes, indexed by the same indexer. The sourcetype is the same for both. I don't explicitly modify the timezone anywhere.
For the first index the _time shown is the right one (same as the one in the log itself).
For the second index the _time is 1 hour behind since the daylight saving time a few days ago. If I look at the _time field, it has however the right date_hour but it shows something different.
I checked on the servers where the logs are generated but they are running the same (and right) timezone: CET.
I am lost about this issue, any suggestions on where I should look?
Hello,
Thank you for your replies.
Finally the "issue" was a bug in Splunk version, by restarting the universal forwarders all went back to normal.
I'm planning the upgrade right now so it should'nt happen again.
Good day.
Hello,
Thank you for your replies.
Finally the "issue" was a bug in Splunk version, by restarting the universal forwarders all went back to normal.
I'm planning the upgrade right now so it should'nt happen again.
Good day.
"The datetime values are the literal values parsed from the event when it is indexed, regardless of its timezone"
That's why I'd rather believe _time (if your time extraction is working properly) than date_* fields.
Hello,
Thanks for your reply.
If I look at the raw datas, the datetime value in the log entry is the one expected, not the wrong one (16:27:16 for the second server, not 15:27:16).
Yes. That's understandable. The date_hour field should correspond to the hour part from the raw event. "local" in date_zone suggests that the timestamp in raw event didn't have the timezone information.
Therefore - if you say that you don't explicitly manipulate timezone - the event must have been parsed according to the local time zone of the HF or indexer. And now the question I cannot answer is whether the data in the raw event is in your local timezone and is not recalculated correctly by the parser or is it sent with a wrong timezone.
Anyway, it looks that some explicit TZ setting could be useful.