The Issue: Even after cleaning the microseconds using gsub the date filter rejects the string. I have tried ISO 8601 yyyy-MM-dd'T'HH:mm:ssXXX and replacing 'T' with a space. The internal state shows the string is "2026-03-04T11:57:52-05:00", but it won't map to UDM.
Question: Has anyone found a specific mutate or date config for Chronicle that handles these -05:00 offsets without failing?
Has anyone seen this where the string looks perfect but the CBN engine rejects it? Is there a hidden character issue or a specific Joda-Time quirk I'm missing?
Best answer by JeremyLand
Try
date { match => ["Time","yyyy-MM-ddTHH:mm:ssZZ"] on_error => "no_match" }
ZZ is the designator for the timezone with the colon. And our date function does automatically handle the ‘T’ as the letter T.
There is a quirk with how our date function handles subsecond precesion. We have special handling in place for all the formats listed in the parser syntax reference docs. Any time you aren’t using one of those EXACT formats you can run into trouble as our function code converts the date format string from the layout the parser expects into the layout the underlying golang time.Parse() function expects. But the good news here is that same golang function automatically handles subsecond precision as part of seconds if you just ignore it. So we can drop anything between the ‘ss’ and the timezone designator.
Other TZ designators the function supports Z - Offset structured HHmm e.g. `-0500` ZZZ - 3 letter timezone abbreviation e.g. ‘MST’
date { match => ["Time","yyyy-MM-ddTHH:mm:ssZZ"] on_error => "no_match" }
ZZ is the designator for the timezone with the colon. And our date function does automatically handle the ‘T’ as the letter T.
There is a quirk with how our date function handles subsecond precesion. We have special handling in place for all the formats listed in the parser syntax reference docs. Any time you aren’t using one of those EXACT formats you can run into trouble as our function code converts the date format string from the layout the parser expects into the layout the underlying golang time.Parse() function expects. But the good news here is that same golang function automatically handles subsecond precision as part of seconds if you just ignore it. So we can drop anything between the ‘ss’ and the timezone designator.
Other TZ designators the function supports Z - Offset structured HHmm e.g. `-0500` ZZZ - 3 letter timezone abbreviation e.g. ‘MST’
