Getting Data In
Highlighted

After modifying the timezone in props.conf, why has the _time field not changed?

Contributor

I've got a variety of customers sending data in to our Splunk indexer. One particular customer has all of their servers set to GMT time (coincidentally our only Linux customer on this particular indexer).

I've modified the props.conf to reflect the following:

[linux_secure]
TZ = GMT

The _time field has not changed. Is this the local (Splunk indexer time) when the event was indexed? Will the _time field never change regardless of TZ change?

The reason for this question is that I have a time reporting in within the event of 2016-02-17T13:44:15.717997+00:00 and a _time field of 2016-02-17T08:44:15.717-05:00 obviously an offset of 5 hours.

Thanks!

0 Karma
Highlighted

Re: After modifying the timezone in props.conf, why has the _time field not changed?

SplunkTrust
SplunkTrust

If the _time is getting adjusted to EST (I believe your Search Head TZ) from GMT value (Offset +00:00), then it's working right? OR I'm reading your question wrong?

0 Karma
Highlighted

Re: After modifying the timezone in props.conf, why has the _time field not changed?

Contributor

So if I want it to stay local time do I set TZ = local?

0 Karma
Highlighted

Re: After modifying the timezone in props.conf, why has the _time field not changed?

SplunkTrust
SplunkTrust

I guess you don't have to use TZ at all as your logs already contain the timezone offset (+00:00). If you sourcetype definition is doing a timestamp recongnition (using TIMEFORMAT attribute) to include timezone offset, it should adjust to the offset properly. Could you post full props.conf entries for sourcetype linuxsecure??

0 Karma
Highlighted

Re: After modifying the timezone in props.conf, why has the _time field not changed?

Contributor

Hi!
I had a similar problem with the timezone, 1 hour of delay, because I have the machine in uk and I'm in UTC Brussels. After searching information about it, I tried to change the timezone for my user on splunk, actually, a collegue did it and we confirmed that this hour of delay, it's not an issue for searches.

However this, just want to say make sure it's a problem, and If it is, I will try to look deeper on it, because then maybe I have the problem too 🙂

Highlighted

Re: After modifying the timezone in props.conf, why has the _time field not changed?

Contributor

So the user thing was exactly it! I created a new user account with GMT as the timezone associated with the account and it came back as expected.

Is there a simple way for this particular source/sourcetype to be viewed with the "local" timestamp of GMT even if a user has a timezone set to Eastern Standard, or any other timezone?

0 Karma
Highlighted

Re: After modifying the timezone in props.conf, why has the _time field not changed?

Contributor

Unfortunately, I don't know 😞 Since I saw that was not a problem for the searches, I leave as a future investigation.

Maybe setting something in the props.conf or the files these guys are saying will help us!

Glad to helped to you and share the problem!

0 Karma
Highlighted

Re: After modifying the timezone in props.conf, why has the _time field not changed?

Influencer

Please encourage all your customers to log their data in UTC. Everyone setting their server time to UTC would make the world a better place. While that is partly facetious, if having UTC across the board is a possibility you should try to make it happen.

I just wanted to answer a part of your question. You asked is [_time] the local (Splunk indexer time) when the event was indexed?

No. There is another field called indextime which has the timestamp of when the log was indexed. If _time and _indextime match, but the actual timestamp is different that can point to issues with timestamp parsing and you should double check your props.conf. However as you have indicated it looks more likely that you have a timezone issue as you are exactly offset by the timezone offset. So most likely you are missing the timezone config in your TIMEFORMAT props.con entry. As @somsesoni2 suggests please post your props.conf for this source type.

A correctly extracted timestamp will most likely solve your problem.