Splunk Parsing dates incorrectly

[steveirogers]

I know there have been other questions asked about splunk parsing dates. However, I have what appears to be a unique situation where I do not understand how Splunk is interpreting dates.

I have the following log entries:

8:58:05.202 PM  [3/6/12 19:58:05:202 EST] 000002f9 LTPAServerObj W SECJ0371W: Validation of the LTPA token failed because the token expired with the following info: Token expiration Date: Tue Mar 06 19:55:26 EST 2012, current Date: Tue Mar 06 19:58:05 EST 2012.

host=fmgpapp05   Options|  sourcetype=RulesOnline   Options|  source=/log/parpapp051/SystemOut.log   Options|  date_mday=12   Options|  date_hour=19   Options|  date_minute=58   Options 

Why is Splunk tagging the log entry as "06/12/11" when the log date is actually "3/6/12"?

[lguinn2]

Why is - Because Splunk sees the first date as the timestamp. But don't worry, you can easily fix that. I assume that the sourcetype for this data is RulesOnline. In $SPLUNK_HOME/etc/system/local/props.conf, put

[RulesOnline]
TIME_PREFIX =\[
MAXTIMESTAMPLOOKAHEAD = 60

This tells Splunk that the timestamp appears AFTER the first [ and that the timestamp appears within the first 60 characters of the event. When there are multiple strings that could be interpreted as timestamps, you sometimes need to give Splunk a little help to pick the right one.

There is more info in the manual here.

[lguinn2]

I think that the time prefix and lookahead will still work. Although I might change the lookahead value to 50 instead of 60. And I am not sure why It messed up the timestamp..

[steveirogers]

Thanks Lguinn. My question might have been misleading and I just want to clarify.
The "6/12/11" is not part of the log entry. The actual log entry is:
8:58:05.202 PM [3/6/12 19:58:05:202 EST] 000002f9 LTPAServerObj W SECJ0371W: Validation of the LTPA token failed because the token expired with the following info: Token expiration Date: Tue Mar 06 19:55:26 EST 2012, current Date: Tue Mar 06 19:58:05 EST 2012

Splunk is creating the log entry as "6/12/11" when I would have expected it to be "03/06/12"