How time zones are determined and why it matters

Since all events are stored according to their GMT time, the time zone of event only matters at parse time, but it is vital to get it right. Once the event is written into the index, it cannot be changed without reindexing the raw data.

The time zone can come from a number of places, in the following order of precedence:

• The time zone specified in the log. For instance, the date 2012-02-07T01:03:23.575-0600, -0600 indicates that the zone is 6 hours behind GMT. Likewise, Tue 02 Feb, 01:03:23 CST 2012 represents the same date.
• The configuration associated with a source, host, or sourcetype, in that order. This is specified in props.conf. This can actually be used to override the time zone listed in the log itself, if necessary. We will discuss this in Chapter 11, Configuring Splunk.
• The time zone of the Splunk instance forwarding the events. The time zone is relayed along with the events, just in case it is not specified elsewhere. This is usually an acceptable default. The exception is when different logs are written with different time zones on the same host, without the time zone in the logs. In that case, it needs to be specified in props.conf.
• The time zone of the Splunk instance parsing the events. This is sometimes acceptable and can be used in interesting ways in distributed environments.
• The important takeaway, again, is that the time zone needs to be known at the time of parsing and indexing the event.