ISO8601 date format not matching %{TIMESTAMP_ISO8601}


I am unable to use the timestamp8601 => ISO8601 define with my current log format.

Log example:
2011-09-01 22:49:26.387 INFO application: Connection state changed

My pattern for the time looks like this:
And the rest (probably irrelevant, but here it is)
CFSERVER %{CFSERVERTIME} %{WORD:severity} %{DATA:application} %{GREEDYDATA:message}

I got a workaround in place by defining my date as such:
date {
type => "cfserver"
timestamp8601 => "yyyy-MM-dd HH:mm:ss.SSS"
timestamp => "MM/dd HH:mm:ss"

If you need more info, just ask. I'm in IRC.

I think ISO8601 should work for this format, so this is a potential bug.


Philippe Weber
August 30, 2014, 6:14 AM

PR Merged

Philippe Weber
April 11, 2014, 7:22 AM
September 18, 2013, 3:50 PM

i have a similar failing format which is not recognized as ISO8601 when surrounded by other characters, even though the short timezone offset is explicitly allowed:
" the zone designator would be "+01:00", "+0100", or simply "+01"."

pattern: %{GREEDYDATA},%{TIMESTAMP_ISO8601:timestamp},%{GREEDYDATA}
"foo,2013-09-18T15:51:43:614+02:00,bar" works.
"foo,2013-09-18T15:51:43:614,bar" works.
"foo,2013-09-18T15:51:43:614+02,bar" does not work.

testable with

Philippe Weber
July 4, 2012, 8:58 AM

In fact JODA is right, a space is not allowed in ISO, only 'T', see

The issue is present for a long-time and remains in logging framework like log4j and logback, but considered minor...
So it may continue to spread the existing confusion.

Now, what to do in Logstash to ensure consistency between grok and date filter ?
I would go for splitting the grok pattern in two, one *real* ISO8601 with the T only, and another one with space and a *very explicit name*,
then from this name, adding a special case to the date filter would be a breeze.
But I have no clue for the name plus it would be a breaking change

Jordan Sissel
September 9, 2011, 12:31 AM


Philippe Weber


Greg Dallavalle