Specify time zones for timestamps
If you index data from different time zones, you can use time zone offsets to ensure that they correlate correctly when you search. You can configure time zones based on the host, source, or source type of an event.
Configure time zones in props.conf. For general information on editing
props.conf for timestamps, see Configure timestamp recognition. If you have Splunk Enterprise and need to modify timestamp extraction, perform the configuration on your indexer machines or, if forwarding data, use heavy forwarders and perform the configuration on the machines where the heavy forwarders run. If you have Splunk Cloud and need to modify timestamp extraction, use heavy forwarder and perform the configuration on the machines where the heavy forwarders run.
How Splunk software determines time zones
To determine the time zone to assign to a timestamp, Splunk software uses the following logic:
- Use the time zone specified in raw event data (for example, PST, -0800), if present.
- Use the
TZattribute set in
props.conf, if the event matches the host, source, or source type that the stanza specifies.
- If the forwarder and the receiving indexer are version 6.0 or later, use the time zone that the forwarder provides.
- Use the time zone of the host that indexes the event.
Note: If you have Splunk Enterprise and you change the time zone setting of the host machine, you must restart Splunk Enterprise for the software to detect the change.
Specify time zones in props.conf
To configure time zone settings, edit props.conf in
$SPLUNK_HOME/etc/system/local/ or in your own custom application directory in
$SPLUNK_HOME/etc/apps/. For information on configuration files in general, see About configuration files in the Admin manual.
Configure time zones by adding a
TZ attribute to the appropriate stanza in
TZ attribute recognizes zoneinfo TZ IDs. See all the time zone TZ IDs in the list of tz database time zones. Inside the stanza for a host, source, or source type, set the
TZ attribute to the TZ ID for the desired time zone. This should be the time zone of the events coming from that host, source, or sourcetype.
You do not configure the time zone for the indexer in Splunk Enterprise, but in the underlying operating system. As long as the time is set correctly on the host system of the indexer, the offsets to event time zones will be calculated correctly.
Examples of time zone specification in props.conf
Following are some examples of how to specify time zones in props.conf.
In the first example, events come into the indexer from New York City (in the US/Eastern time zone) and Mountain View, California (US/Pacific). To correctly handle the timestamps for these two sets of events, the
props.conf for the indexer needs the time zone to be specified as US/Eastern and US/Pacific, respectively.
The first example sets the time zone to US/Eastern for any events coming from hosts whose names match the regular expression
[host::nyc*] TZ = US/Eastern
The second example sets the time zone to US/Pacific for any events coming from sources in the path
[source::/mnt/ca/...] TZ = US/Pacific
zoneinfo (TZ) database
The zoneinfo database is a publicly maintained database of time zone values.
- UNIX versions of Splunk software rely on a TZ database included with the UNIX distribution you're running on. Most UNIX distributions store the database in the directory:
- Solaris versions of Splunk software store TZ information in this directory:
- Windows versions of Splunk software ship with a copy of the TZ database.
Refer to the list of tz database time zones for all permissible
Map timezone strings extracted from event data
TZ_ALIAS attribute in
props.conf to change how Splunk software interprets the timezone acronym string occurring in event data. For example, "EST" means Eastern (US) Standard Time by default, but your event data might be using that value instead to designate Eastern (Australian) Standard Time. To change the meaning of "EST" to the latter, set the attribute like this:
TZ_ALIAS = EST=GMT+10:00
Then, when Splunk software encounters "EST" in event data, it will interpret it as "GMT+10:00", rather than the default of "GMT- 5:00".
As this example shows, you can map a timezone string to an existing string plus offset value. You can also just map one TZ string directly to another.
When mapping timezone strings, be sure to handle both summer and winter versions of the time zones. If mapping EST, also map EDT, for example - depending on whatever your local pairs are. Test your software to see what timezone strings it produces.
You can specify multiple mappings. The syntax for
TZ_ALIAS = <key=value>[,<key=value>]...
For more information, including examples, see the props.conf specification and example file in the Configuration File Reference.
Set the time zone for a user's search results
When you add or edit users using Splunk authentication, you can set a user time zone. Search results for that user will appear in the specified time zone. This setting, however, does not change the actual event data, whose time zone is determined at index time. For information on setting this value, see Configure users with Splunk Web in the Securing Splunk manual.
Configure advanced timestamp recognition with datetime.xml
Tune timestamp recognition for better indexing performance
This documentation applies to the following versions of Splunk® Enterprise: 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.1.0, 8.1.1, 8.1.2, 7.0.2, 7.0.3, 7.0.4