How time zones are processed by the Splunk platform
The Splunk platform processes time zones when data is indexed and when data is searched.
When data is indexed, the Splunk indexer looks for a timestamp in each event. The timestamp might be in one of several formats, as shown in the following table:
Type of timestamp | Timestamp example | Description |
---|---|---|
UNIX time | 1523644307 | In seconds |
1523644307000 | In milliseconds | |
Human-readable format | 04/13/2018 11:45:30 PDT | US Pacific Daylight Time, the timezone where Splunk Headquarters is located. |
Friday, April 13, 2018 11:45:30 AM GMT -07:00 | A timestamp with an offset from GMT (Greenwich Mean Time) | |
2018-04-13T11:45:30Z | A timestamp expressed in UTC (Coordinated Universal Time) | |
2018-04-13T11:45:30-07:00 | The local time representation of a UTC time, which is expressed with an offset. | |
Local time with no time zone | 10:55AM | The local time is interpreted as the same time zone as the Splunk indexer where the data is indexed. |
Timestamps are stored in UNIX time
Regardless of how time is specified in your events, timestamps are converted to UNIX time and stored in the _time
field when your data is indexed. If your data does not have timestamps, the time at which your data is indexed is used as the timestamp for your events.
UNIX time is the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), 1 January 1970. This moment in time is sometimes referred to as epoch time.
GMT and UTC
GMT (Greenwich Mean Time) is sometimes confused with UTC (Coordinated Universal Time). However GMT is a time zone and UTC is a time standard.
- GMT is a time zone officially used in some European and African countries as their local time. The time is displayed in either the 24-hour format (00:00-23:59) or the 12-hour format (00:00-12:00 AM/PM).
- UTC is a time standard that is the basis for time and time zones worldwide. No country uses UTC as a local time.
- Neither GMT nor UTC ever change for Daylight Saving Time (DST). However, some of the countries that use GMT switch to different time zones during their DST period. For example, the United Kingdom uses GMT for most of the year, but switches to British Summer Time (BST) during the summer months. BST is one hour ahead of GMT.
What time zone is used for timestamps
When data is indexed and added to your Splunk instance, the Splunk indexer assumes that any timestamps in the data are in the same time zone as your Splunk instance.
Let's use a set of test data that contains 35 events with various timestamps. The data looks something like this:
timestamp | test_no |
---|---|
2018/10/1 00:00 | tz_test0 |
2018/10/1 00:15 | tz_test1 |
2018/10/1 01:00 | tz_test2 |
2018/10/1 01:30 | tz_test3 |
2018/10/1 01:45 | tz_test4 |
2018/10/1 02:00 | tz_test5 |
2018/10/1 02:30 | tz_test6 |
You can see how the timestamp is processed in the Add Data wizard on the Set Source Type step, for example when you add a CSV file. The values in the timestamp
field in the sample data file are converted to UNIX time and stored in the _time
field when the data is indexed. However, for display purposes the values in the _time
field are shown in a human-readable format.
The values in the _time
field are the same as the values in the timestamp
field in the sample data file because the Splunk indexer assumes that the values in the timestamp
field are in the same time zone as the Splunk instance. The default method used to extract timestamps from your data is set to Auto.
Timestamp extraction methods
Most events do not require special timestamp handling. The Splunk indexer automatically recognizes and extracts the timestamps. Use these other methods only if you discover that the Splunk indexer is not extracting timestamps correctly.
In the Add Data wizard on the Set Source Type step, these are the Timestamp options:
In addition to the Auto timestamp extraction method, there are other methods for timestamp extraction when you index data:
- Current time
- Sets the timestamp to the current clock time. Ignores the timestamps in the fields in the data.
- Advanced
- You can specify the Time Zone, the Timestamp format using the
strptime()
function, and the Timestamp fields when multiple fields comprise the complete timestamp. See thestrptime()
function in Date and Time Functions in the Search Reference.
- Configuration file
- You can specify a configuration file for custom timestamp extractions from your event data. The configuration file must reside in
$SPLUNK_HOME
and have an XML extension.
Indexing events using a different time zone
Maybe you want some data indexed using a different time zone than the default time zone. You can specify the time zone in the Add Data wizard.
For example, let's say your Splunk instance is in San Francisco, California, which is in the US Pacific time zone. You are in an office in Tokyo, which is in the Japanese time zone. The data is from October, a time when the US uses daylight saving time. The time zone in the US is referred to as Pacific Daylight Time (PDT). Japan does not have daylight saving time. The time zone for Tokyo is Japan Standard Time (JST). You want to index the data using Japan Standard Time instead of the timezone of the Splunk instance in California.
In this example, the data is in a CSV file.
To access the Add Data wizard in Splunk Web:
- From the Settings menu click Upload.
- In the Set Source Type step of the Add Data wizard, click Timestamp, Advanced, and then Time Zone.
- Select the time zone that you want to use. In this example, the selected time zone is (GMT+09:00) Osaka, Sapporo, Tokyo.
When you select a different time zone, the values in the _time
field reflect the timezone you specify when you index the data. In this example, this is the Japanese time zone. These timestamps are equivalent to the timestamps where the Splunk instance is located. In this example, this is the Pacific Daylight Time (PDT).
Remember, timestamps are stored in UNIX time. However, time is displayed in the _time
field in a human-readable format. In this example, the values in the _time
field are 16 hours earlier than the timestamp values in the Tokyo time zone.
Location | Timestamp | UNIX time | Description |
---|---|---|---|
Toyko (JST) | 2018/10/1 00:00 | 1538352000 | Midnight or 2400 hours. GMT + 09:00 hours. |
GMT | 2018/09/30 15:00 | 1538352000 | Nine hours behind Japan, which is equivalent to 15:00 hours on September 30th. GMT + 00:00 hours. |
San Francisco (PDT) | 2018/09/30 08:00 | 1538352000 | Seven hours behind GMT. 16 hours behind Japan, which is equivalent to 08:00 hours on September 30th. GMT - 07:00 hours. |
Notice that the UNIX time does not change. What changes is the time in each time zone that is equivalent to the UNIX time.
How time is interpreted when you search
When you specify a time in your search, either by using the time range picker or using time modifiers, the time that you specify is converted into UNIX time for processing. See Select time ranges to apply to your search and Specify time modifiers in your search.
Because event timestamps are stored in UNIX time, your searches return a consistent set of results regardless of the time zone you are in.
For example, if you search from 12:00 to 14:00 PDT (Pacific Daylight Time), that is the same as searching from 19:00 to 21:00 GMT (Greenwich Mean Time) which is 7 hours ahead of PDT. When daylight saving time is over, Pacific Standard Time (PST) is used. The difference between GMT and PST is 8 hours.
In Splunk Web, the values in the _time
field appear in a human-readable format in the UI. However, the values in the _time
field are actually stored in UNIX time.
How time zones impact search results
The time range that you specify for a search might return different sets of events in different time zones.
This can occur for time ranges that you specify using the time range picker and time ranges that you specify explicitly in the search with the earliest
and latest
time modifiers, Here are some examples:
- If you use the default Last 24 hours time range picker setting, the search processes the events using UNIX time. The same set of events are returned for a user in San Francisco and a user in Tokyo.
- If you use a time range that refers to a time associated with today such as Since 00:00:00, the search processes events based on midnight of your time zone, not UNIX time. A different set of events are returned for a user in San Francisco and a user in Tokyo, because the time that midnight occurs is different in each timezone. There are several settings in the time range picker that fall into this category, such as the Preset setting Today and the Date Range setting Since <today's date>.
- If you use a snap-to time, such as
@d
or@mon
, the search processes events based on the beginning of the day or month of your timezone, not UNIX time. A different set of events are returned for a user in San Francisco and a user in Tokyo, because the beginning of a day or month in one time zone is not the same UNIX time as the beginning of a day in another time zone.
To mitigate the issues with time zones, specify time based on the time zone where the Splunk indexer resides.
See also
- Getting Data In
- * How timestamp assignment works
- * Specify time zones for timestamps
- * The Set Source Type page
- Securing Splunk Platform
Search using time bins and spans | About subsearches |
This documentation applies to the following versions of Splunk® Enterprise: 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.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.1.11, 8.1.12, 8.1.13, 8.1.14, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.3.0, 9.3.1, 9.3.2, 9.4.0
Feedback submitted, thanks!