The answer in short is No. If TZ is embedded into the event, the Indexer will trust the embedded TZ explicitly and ignore any instructions that are given regarding timestamp in props.conf, irrespective of variance.
There is only 1 way to override an in-event TZ setting and that is with TZ_ALIAS
; read about it here:
http://docs.splunk.com/Documentation/Splunk/latest/Admin/Propsconf
This would be correct for version 6.X.
The answer in short is No. If TZ is embedded into the event, the Indexer will trust the embedded TZ explicitly and ignore any instructions that are given regarding timestamp in props.conf, irrespective of variance.
Actually, @jbsplunk is correct. The timestamp on this question was from Feb 26, 2013. At the time, Splunk 4.3 was the de-facto version, Splunk 5 would be released during .conf2013. So according to the correct documentation, http://docs.splunk.com/Documentation/Splunk/4.3.6/admin/Propsconf, the TZ
option was the only option. TZ_ALIAS
wasn't an option until Splunk 6.0.
This is incorrect; you can use TZ_ALIAS
to override in-event TZ
values (see my answer).
I just care about the added workload of having to process a TZ at all vs having the event use GMT (or the same TZ as my indexer.) Sounds like there is no added "load" with an embedded TZ.
The longer answer is that Splunk may not automatically recognize the TZ offset expression. If you're using a common pattern, Splunk should recognize it, but if it's less common you may need a TIME_FORMAT to specify where the offset is located.