Specify time zones for timestamps
If you index data from different time zones, you can use time zone offsets to check that they correlate correctly when you search. You can configure time zones based on the host, source, or source type of an event.
To modify timestamp extraction, your Splunk Cloud Platform architecture must include a heavy forwarder and you must edit the props.conf file on the heavy forwarder. Perform the configuration on the machines where your heavy forwarders run.
If you change the time zone setting of the host machine, you must restart Splunk Enterprise or the forwarder for the software to detect the change.
For general information on editing timestamps in the props.conf. file, see Configure timestamp recognition.
If you have Splunk Enterprise and need to modify timestamp extraction, perform the configuration on your indexer machines or, if you are forwarding data, use heavy forwarders 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 in order of precedence:
- 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 higher, use the time zone that the forwarder provides.
- Use the time zone of the host that indexes the event.
If Splunk has multiple specified time zones, it will use the one higher in precedence.
Specify time zones in props.conf
To configure time zone settings, edit the props.conf file in
$FORWARDER_HOME/etc/system/local/ or in your own custom application directory in
$FORWARDER_HOME/etc/apps/. For information on configuration files in general, see About configuration files in the Splunk Enterprise Admin Manual.
Configure time zones by adding a
TZ attribute to the appropriate stanza in the props.conf file. The
TZ attribute recognizes zone info TZ IDs. Inside the stanza for a host, source, or source type, set the
TZ attribute to the TZ ID for the desired time zone. Make sure that the time zone of the events you enter is the time zone coming from that host, source, or source type.
To view a list of all the time zone TZ IDs, see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones.
You do not configure the time zone for the indexer on the Splunk Platform, but instead 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 are calculated correctly.
Examples of time zone specification in props.conf
The following are examples of how to specify time zones in props.conf.
In the first example, events come into the forwarder from New York City in the U.S./Eastern time zone and Mountain View, California in the U.S./Pacific time zone. To correctly handle the timestamps for these two sets of events, you must set the time zone for the props.conf for the forwarder to be specified as U.S./Eastern and U.S./Pacific respectively.
The first example sets the time zone to U.S./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 U.S./Pacific for any events coming from sources in the path
[source::/mnt/ca/...] TZ = US/Pacific
zoneinfo (TZ) database time zone values
The zoneinfo database is a publicly maintained database of time zone values. The location and content of the TZ database depend on your operating system. The following list shows the locations of the TZ database for several common operating systems.
- 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
- Solaris versions of Splunk software store TZ information in the
- Windows versions of Splunk software ship with a copy of the TZ database.
See list of tz database time zones for a list of tz database time zones.
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 (U.S.) 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 using the following syntax:
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 its offset value. You can also map one TZ string directly to another.
When mapping timezone strings, be sure to handle both summer and winter versions of the time zones. For example, if you map Eastern Standard Time, you must also map Eastern Daylight Time. Test your software to see what timezone strings it produces.
The syntax for
TZ_ALIAS = <key=value>[,<key=value>]...
For more information about editing the props.conf file, including examples, see the props.conf specification in the configuration file reference chapter of the Splunk Enterprise Admin Manual.
Set the time zone for a user's search results
When you add or edit users, you can set a user time zone. Search results for that user 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 Create and manage users with Splunk Web in the Securing the Splunk Platform 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.5.7, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 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.4, 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.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.10, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 7.3.3, 7.3.5, 7.3.6