Splunk® Enterprise

Getting Data In

Download manual as PDF

Download topic as PDF

Configure timestamp recognition


There are two ways to configure timestamp extraction:

  • Edit props.conf directly, as explained in this topic.


The timestamp processor



Edit timestamp properties in props.conf





Syntax overview

An overview of the syntax for the timestamp attributes follows:

DATETIME_CONFIG = <filename relative to $SPLUNK_HOME>
TIME_PREFIX = <regular expression>
TIME_FORMAT = <strptime-style format>
TZ = <POSIX time zone string>
MAX_DAYS_AGO = <integer>
MAX_DAYS_HENCE = <integer>
MAX_DIFF_SECS_AGO = <integer>

In this syntax, <spec> can be:

  • <sourcetype>, the source type of an event.


Timestamp validity attributes and their impact on events





Timestamp attributes

You can set the following timestamp attributes with props.conf.

Attribute Description Default








empty string

This constraint is applied starting from the location positioned by TIME_PREFIX.



128 characters





empty string


empty string





The value is another TZ specifier that expresses the desired offset.


not set


The maximum settable number of days in the past is 10951.

2000 days







The maximum settable number of days is 10950.

2 days


The maximum settable number of seconds is 2147483646.

3600 seconds (1 hour)


The maximum settable number of seconds is 2147483646.

604800 seconds (1 week)

Enhanced strptime() support



%+ For standard Unix date format timestamps.
 %v For BSD and OSX standard date format.
%s Epoch (10 digits)


strptime() format expression examples


1998 years, 312 days  %Y years, %j days
Jan 24, 2003  %b %d, %Y
January 24, 2003  %B %d, %Y
1397477611.862  %s.%3N



Your data might contain an easily recognizable timestamp, such as:


To extract that timestamp, add this stanza in props.conf:

TIME_FORMAT = %m/%d/%y

Another example that includes time zone information:


To extract the timestamp, add this to props.conf:

TIME_PREFIX = Valid_Until=







Configure timestamps for specific needs


Configure how timestamps appear in search results


Reconfigure how timestamps appear in raw data


Assume the timestamp data in the raw event looks like this:

06/07/2011 10:26:11 PM


07/06/2011 10:26:11 PM


In transforms.conf, add this stanza:

FORMAT = $2/$1/$3 $4
DEST_KEY = _raw 


TRANSFORMS-sortdate = resortdate



How timestamp assignment works
Configure timestamp assignment for events with multiple timestamps



how do you assign TIME to a field called "time" in your sourcetype definition?

September 18, 2018

Where should i put timestamp configurations?

1. If you are using INDEXED_EXTRACTIONS = <.. > then put it to the server where INDEXED_EXTRACTION is configured.
2. If you are using Heavy forwarder then put it in the heavy forwarder
3. If you are using Indexer only then put it in the indexers.

Sylim splunk, Splunker
June 28, 2018

"For GNU date-time nanoseconds." The only thing GNU here is the %N convention. "For milliseconds, microseconds for Apache Tomcat." This is not for apache tomcat. It's just accepting the %Q and %q conventions used by apache tomcat. "For standard Unix date formats". Unix does not have a standard date format. Unix "time_t" or seconds from epoch are what you're looking for here. Saying %v is "standard bsd osx" is unhelpful. Say " 1-Jan-2012", though I don't see the point of ever using this. %Z behavior underdefined . what does "nothing" mean? Probably it's UTC if not recognized. :-/

October 24, 2017

Hi Lguinn,

I'm researching this now, but I would like to think that yes, we do, since we support an enhanced version of the format.

I will confirm and update here. Thanks for your patience.

Malmoore, Splunker
January 20, 2017

Does the Splunk implementation of strptime support %t and %n? Also, I think the specification for these has changed within the last few years. What rev of the strptime standard does Splunk support?

Lguinn, Splunker
January 17, 2017

Hi BradTaylor,

You're right, it does look like the examples you show are missing the strptime token for day of week. I think the second does account for the day of week because of the \w+\s regular expression, but the first one is a no-brainer. I'll fix this.


Malmoore, Splunker
November 7, 2016

For these two examples:

TIME_PREFIX = Valid_Until=



The timestamps both have Day of Week tokens. But there is no %a leading strptime token to capture that. (Maybe it's not required in the second example because of the \w+\s regex pattern... fair enough. But what about the first one?)

November 3, 2016

HI Graham Hannington,

I am still researching information on your previous comment. I should have answers for you shortly (though it will likely not be until after .conf.)

I'll make updates to the topic again at that time based on that information.

Malmoore, Splunker
September 28, 2016

Some nits in the description of "%z, %:z, %::z":

- Missing closing parenthesis.
- Misplaced periods next to closing parentheses. Unless parentheses enclose a complete sentence, the period should follow the closing parenthesis.
- "ISO-8601-style"? All those hyphens! "Numeric"? I get that you're distinguishing these formats from the uppercase %Z, but since you namecheck ISO 8601, perhaps use its terminology. "ISO 8601 zone designator"? (And I have "Hyphenate compound adjectives" tattooed in blackletter across my midriff!)
- Consistency: timezone (one word) versus time zone (two: this is the term that ISO 8601 uses).

All minor, but this stuff sticks out to me like dogs' balls. Yes, my problem, but these comments give me the opportunity to vent ;-).

Suggestion: rewrite in a tabular, reference style, as per other formats. Rather than nesting the descriptions, three separate rows. Or reuse:


Graham Hannington
September 26, 2016

In practice, the %6N (note the width: 6 decimal places, for microsecond precision) in

TIME_FORMAT = %Y-%m-%d %H:%M:%S.%6N%:z

also recognizes time stamps with millisecond precision (3 decimal places).

That is, Splunk correctly recognizes both of the following time stamps (and Splunk Web displays them correctly):

2016-09-23 08:00:00.123+08:00
2016-09-23 08:00:00.123456+08:00

with or without the trailing zone designator (+08:00)

Shrug. So what?

Here's why it matters to me: I'm documenting example .conf stanzas for ingesting data from an application that I'm helping to develop. Users can configure that application to output time stamps with millisecond or microsecond precision. I was wondering whether I'd have to warn users about specifying the correct "sub-second width", %3N or %6N, in TIME_FORMAT. Turns out I don't have to: %6N works for both.

Splunk, please feel free to correct me.

Graham Hannington
September 22, 2016

Hi all,

I've made updates to the page to better clarify the %Z and %[:][:]z strptime() settings. Zerone is correct in that the colons in the %z setting represent how to split the timezone offset. The %:::z setting is a typo and has been removed.

Malmoore, Splunker
September 1, 2016

%z works for +1000 (-1000), will stop at +10 for time offset of +10:00 or +10:00:00
%:z works for +1000 (-1000) and +10:00 (-10:00), will stop at +10:00 for time offset of +10:00:00
%::z works for +1000 (-1000) and +10:00:00 (-10:00:00), will error for (+10:00 or -10:00), will stop at +10:00:00 for time offset of +10:00:00:00

May 8, 2016

Could you please provide more detail in this topic, or a link to details elsewhere, on the formats (the IEEE/Open Group doc refers to these as "conversion specifications") for time zones?

I discovered in Splunk Answers that the following format:


(note the single colon)

was what I needed to match an ISO 8601 extended format zone designator such as:


but this Splunk docs topic does not mention that specific format (%:z, with the single colon).

The topic *does* mention "GNU libc support", but the topic at the following link:


only mentions %z and %Z, not any variants with colons. (That is, %z matches a "basic format" ISO 8601 zone designator such as +0800, not an "extended format" designator with a colon separator.)

Graham Hannington
May 4, 2016

Hi Woodcock,

Splunk Enterprise never drops events if event timestamps are outside of the acceptable window. The default for MAX_DAYS_AGO is 2000 which means that timestamps can be askew for nearly 5 1/2 years before the software has to decide what to do with the events. In nearly all cases, it uses the timestamp of the previous event. If it can't determine the timestamp of the previous event, it uses the time that the event was indexed. The default for MAX_DAYS_HENCE is 2, but the resolution logic is the same.

Malmoore, Splunker
March 6, 2016

For MAX_DAYS_AGO and MAX_DAYS_HENCE, when the timestamp is outside of the acceptable window, what happens when "the date is ignored"? Does it:
1: Use _indextime?
2: Use the timestamp of the previous event?
3: Drop the event entirely?
This detail should be included in the documentation.

February 27, 2016

Was this documentation topic helpful?





0 out of 1000 Characters