Why am I seeing timezone differences for sourcetypes on the same host?

[rune_hellem]

Indexing log files from a couple of IIS-servers. The events being logged are logged as GMT, whereas the time here in Oslo is GMT+2 during summertime. So for sourcetype IIS it is all correct. The raw event is for instance 10:00, but the time in Splunk shows 12:00.

Problem is for my custom sourcetype IISAdvanced, defined in props.conf. I have specified TZ = Europe/Oslo (previously tried TZ = CET), done ** Splunk reload deploy-server** and then restarted search head and indexer. But no help. Both Splunk time and event time is equal, so Splunk does not understand my timezone instruction.

Sourcetype defined like this

[iisadvanced]
pulldown_type = true
MAX_TIMESTAMP_LOOKAHEAD = 32
SHOULD_LINEMERGE = False
CHECK_FOR_HEADER = False
TZ = Europe/Oslo
REPORT-iisadvancedfields = iisadvancedfields
TRANSFORMS-removecomments = removecomments

BTW: Splunk 6.2.2 on Windows 2012 server, indexer on 2008 server.

Adding screenshots
This is the default sourcetype IIS, where timezone is handeled correctly

and this is the custom sourcetype IISAdvanced where timezone is not handeled correctly, both Splunk time and raw time is identical.

[chimell · Accepted solution]

Hi rune.hellem
Look at the instruction of defining the timezone in props.conf file .It will help you

TZ  =<timezone identifier>

The algorithm for determining the time zone for a particular event is
as follows:

• If the event has a timezone in its raw text (for example, UTC,
  -08:00), use that.

• If TZ is set to a valid timezone string,use that.

• If the event was forwarded, and the forwarder-indexer connection is
  using the
  6.0+ forwarding protocol, use the timezone provided by the forwarder.

• Otherwise, use the timezone of the system that is running splunkd.

• Defaults to empty.

[chimell]

good thanks

[rune_hellem]

Got it

Otherwise, use the timezone of the system that is running splunkd.

I did use Europe/Oslo, which is the timezone of the searchhead. Changed to Etc/GMT, the timezone of the server running the forwarder, problem solved.