Study guide
16.2 Timestamp Extraction, Time Zones & Clock Skew Handling
Splunk Enterprise Certified Admin SPLK-1003
Track your progress as you read
Finished sections get a check mark.
1 Introduction
About the Splunk Enterprise Certified Admin Exam
2 Chapter 1: Splunk Admin Basics
1.1 Splunk Enterprise Architecture & Core Components
3 Chapter 2: License Management
2.1 License Types, Stacks, Pools & Licensing Architecture 2.2 License Violations, Rolling Window Warnings & Troubleshooting
4 Chapter 3: Splunk Configuration Files
3.1 Splunk Configuration Directory Structure 3.2 Configuration Layering, Precedence & Resolution Rules 3.3 Using btool to Inspect & Debug Configurations
5 Chapter 4: Splunk Indexes
4.1 Index Structure: Directories, Buckets & Bucket Files 4.2 Bucket Types & the Hot-Warm-Cold-Frozen-Thawed Lifecycle 4.3 Checking Index Data Integrity 4.4 indexes.conf Options: Paths, Bucket Sizing & Volumes 4.5 The Fishbucket: File Tracking, CRC Collisions & Re-reading Files 4.6 Applying a Data Retention Policy
6 Chapter 5: Splunk User Management
5.1 Splunk Roles, Capabilities & Custom Role Design 5.2 User Account Administration, Search Restrictions & Limits
7 Chapter 6: Splunk Authentication Management
6.1 Integrating Splunk with LDAP 6.2 Other Authentication Options & Enabling Multifactor Authentication
8 Chapter 7: Getting Data In
7.1 CLI Administration & Basic Data Onboarding Workflows 7.2 Forwarder Types: Universal Forwarder vs. Heavy Forwarder
9 Chapter 8: Distributed Search
8.1 How Distributed Search Works 8.2 Roles of the Search Head and Search Peers 8.3 Configuring Search Peers & Distributed Search Groups 8.4 Search Head Scaling & Search Head Clustering (SHC)
10 Chapter 9: Getting Data In – Staging
9.1 Ingestion Pipeline Stages: Input, Parsing, Merging, Typing & Indexing 9.2 Pipeline Component Placement & Queue Management 9.3 Splunk Input Options
11 Chapter 10: Configuring Forwarders
10.1 Forwarder Setup & outputs.conf Load Balancing 10.2 Indexer Acknowledgment, Data Cloning & Forwarder Routing
12 Chapter 11: Forwarder Management
11.1 Deployment Management & the Deployment Server 11.2 Deployment Apps & Deployment Clients 11.3 Server Classes, Client Grouping & App Deployment Strategies 11.4 Forwarder Management Monitoring & Troubleshooting
13 Chapter 12: Monitor Inputs
12.1 File & Directory Monitoring Mechanics 12.2 Monitor Input Tuning: Whitelists, Blacklists & CRC Settings 12.3 Deploying a Remote Monitor Input, Network Shares & Archives
14 Chapter 13: Network and Scripted Inputs
13.1 Creating Network Inputs: TCP & UDP 13.2 Optional Settings for Network Inputs 13.3 Scripted Inputs & PowerShell Data Collection
15 Chapter 14: Agentless Inputs
14.1 Windows Management Instrumentation (WMI) Inputs 14.2 HTTP Event Collector (HEC) Architecture & Administration
16 Chapter 15: Fine Tuning Inputs
15.1 Input-Phase Processing & Default Metadata Assignment 15.2 Character Set Encoding & Handling Binary Data
17 Chapter 16: Parsing Phase and Data
16.1 Line Breaking & Event Segmentation 16.2 Timestamp Extraction, Time Zones & Clock Skew Handling 16.3 Validating Event Parsing with Data Preview
18 Chapter 17: Manipulating Raw Data
17.1 Transformation Mechanics: props.conf & transforms.conf 17.2 Data Masking, Redaction & SEDCMD 17.3 Event Routing, Dynamic Index Assignment & Filtering to nullQueue
16.2 Timestamp Extraction, Time Zones & Clock Skew Handling
Key Takeaways Explain This Topic AI
TIME_PREFIX limits the search to text after its first match (no match means no extraction), TIME_FORMAT gives the strptime layout, and MAX_TIMESTAMP_LOOKAHEAD (default 128) bounds the search from the prefix.
Time zone order per props.conf.spec: a zone in the event's raw text first, then TZ in props.conf, then the forwarder's zone, then the zone of the system running splunkd.
DATETIME_CONFIG = NONE keeps the input layer's time (a file's modification time for monitored files); CURRENT uses the time the event passes through the aggregator.
When no timestamp is found, Splunk uses the previous event's time from the same source, then a date in the source name, then the file modification time, then the current time.
MAX_DAYS_AGO (default 2000) and MAX_DAYS_HENCE (default 2) do not drop events; out-of-range dates get the last acceptable event's timestamp, or the current time if none exists.
Last updated: September 2026
Timestamp Extraction, Time Zones & Clock Skew Handling
Quick Summary: Every event's _time is stored as a UTC epoch value. Splunk finds the timestamp during the merging pipeline, using datetime.xml patterns unless you tell it exactly where and how to look with TIME_PREFIX , TIME_FORMAT , and MAX_TIMESTAMP_LOOKAHEAD . Know the time zone order from props.conf.spec (a zone in the event text, then TZ , then the forwarder's zone, then the indexer's zone), what DATETIME_CONFIG = NONE and CURRENT do, the fallback when no timestamp is found, and how MAX_DAYS_AGO and MAX_DAYS_HENCE handle implausible dates.
Timestamp Extraction in props.conf
Without specific settings, Splunk looks for a timestamp using the patterns in $SPLUNK_HOME/etc/datetime.xml (the default DATETIME_CONFIG ). That works for many common formats, but it has costs:
Performance: checking many patterns in every event is slower than parsing one known format.
Wrong matches: numbers such as version strings, IDs, or IP-like values can be mistaken for dates, and the wrong date may be chosen when an event contains several.
Three settings make extraction precise and fast.
1. TIME_PREFIX = <regex>
Splunk looks for a timestamp only in the text after the end of the first match of this regex.
If TIME_PREFIX is not found in the event, timestamp extraction does not occur for that event, and the fallback rules below apply.
Used together with TIME_FORMAT , the prefix must match up to and including the character just before the date. # Timestamp right after an opening bracket
TIME_PREFIX = ^\[
- # Timestamp inside a key-value pair
- TIME_PREFIX = timestamp="
- 2. TIME_FORMAT = <strptime-style format>
Gives the exact strptime layout of the timestamp, read starting right after TIME_PREFIX .
For good results, the format should describe both the date and the time of day.
- Directive Meaning Example
- %Y / %y 4-digit / 2-digit year 2026 / 26
- %m Month number (01–12) 09
- %b / %B Abbreviated / full month name Sep / September
- %d Day of month (01–31) 23
- %H / %I Hour, 24-hour / 12-hour 14 / 02
- %p AM or PM PM
- %M / %S Minute / second 35 / 10
- %3N / %6N Milliseconds / microseconds 124 / 124512
- %z UTC offset -0700
- %Z Time zone abbreviation UTC , EST
- %s Epoch seconds 1790174110
- 3. MAX_TIMESTAMP_LOOKAHEAD = <integer>
How many characters into the event, counted from the TIME_PREFIX location , Splunk looks for the timestamp. If TIME_PREFIX lands 11 characters in and the lookahead is 10, extraction is limited to characters 11 through 20.
Default: 128 .
0 or -1 removes the limit, which the spec warns can hurt performance for long events.
Set it to about the length of the timestamp, for example 30 for an ISO 8601 string with milliseconds and offset.
- Example: A Tuned Source Type [app:json:audit]
- SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)\{"timestamp":
- TIME_PREFIX = \{"timestamp":"
- TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3N%z
- MAX_TIMESTAMP_LOOKAHEAD = 30
- TRUNCATE = 100000
- Time Zone Resolution
Splunk stores _time in UTC and shows it in each user's time zone preference. To convert a timestamp to UTC, it decides the event's zone using the order defined in props.conf.spec for TZ : 1. A time zone in the event's raw text (for example UTC, -08:00, +0000)
- | if none
- v
- 2. The TZ setting in props.conf (for example TZ = America/Chicago)
- | if not set
- v
- 3. The time zone sent by the forwarder (6.0+ forwarding protocol)
- | if not forwarded
- v
- 4. The time zone of the system running splunkd (the parsing instance)
- What This Means in Practice
TZ does not override an explicit zone in the event. If the event says +0000 , that offset is used even when the stanza sets TZ = America/Chicago . TZ fixes events that carry no zone information.
Forwarded data defaults to the forwarder's zone. A universal forwarder in London sends its time zone with the data, so un-zoned timestamps from its files are interpreted as London time, even if the indexer is in New York.
Direct network inputs have no forwarder zone. A London router sending BSD syslog (for example Oct 14 04:12:01 , with no year or zone) straight to a New York indexer is interpreted in the indexer's zone, and its events appear five hours off. Fix it with TZ in a [host::<router>] or source type stanza.
Ambiguous abbreviations: TZ_ALIAS controls how zone strings found in event text are interpreted. For example, EST maps to US Eastern by default; TZ_ALIAS = EST=GMT+10:00 changes that. It has no effect on the TZ setting.
- DATETIME_CONFIG and Fallback Behavior
- DATETIME_CONFIG
- Value Behavior
- /etc/datetime.xml (default) Normal timestamp extraction using datetime.xml patterns, or your TIME_* settings
NONE The timestamp extractor does not run. The event keeps the time chosen by the input layer : for forwarded data, the time chosen on the forwarder; for monitored or batch files, the file's modification time ; for other inputs, the current system time when the data is read
CURRENT Every event gets the current system time at the point it passes through the aggregator (the merging pipeline)
A custom file path Use a different datetime.xml, for example in an app
Both NONE and CURRENT disable timestamp identification in the text. BREAK_ONLY_BEFORE_DATE then cannot find event boundaries, so the spec pairs them with SHOULD_LINEMERGE = false or explicit BREAK_ONLY_* and MUST_BREAK_* rules. The spec notes that turning timestamp extraction off can speed up indexing.
When No Timestamp Is Found
If extraction runs but finds nothing usable, Splunk falls back in this order:
The timestamp of the previous event from the same source.
If no events in the source have a date, a date found in the source or file name (the events need a time of day).
For files, the file's modification time .
As a last resort, the current system time when the event is indexed.
Guardrails: MAX_DAYS_AGO and MAX_DAYS_HENCE
Both limits are measured from the current date as provided by the input layer , such as the forwarder's current time or a file's modification time.
MAX_DAYS_AGO
Default: 2000 days (about 5.48 years). The highest legal value is 10951 (30 years).
An extracted date older than this is not trusted. The event is still indexed , with the timestamp of the last acceptable event , or the current time if there is none.
Backfilling old archives: when loading data older than 2000 days, increase MAX_DAYS_AGO for that source type first. Otherwise, those events are stamped with other events' times.
MAX_DAYS_HENCE
Default: 2 days, which allows dates up to one day in the future. The highest legal value is 10950 .
A date further in the future gets the timestamp of the last acceptable event , or the current time if none exists.
If servers have the wrong date, or are in a time zone a day ahead, the spec suggests increasing it to at least 3. A smaller window makes false positives less likely.
Wildly wrong future dates are worth preventing, because they also stretch the time range of the bucket that holds them. That affects which searches must open the bucket and when time-based retention can freeze it.
Related: MAX_DIFF_SECS_AGO / MAX_DIFF_SECS_HENCE
These settings (defaults 3600 seconds and 604800 seconds) do not filter events. They make Splunk warn about timestamps that jump backward or forward compared with the previous event, and use a different format from most events in the source.