Logstash Date Filter Plugin

The Logstash date filter plugin parses a date string from a named field and stores the result in a timestamp field, which is @timestamp by default. The plugin accepts multiple Joda-Time patterns, the special keywords ISO8601, UNIX, UNIX_MS, and TAI64N, and can override the event's timezone. Use it to normalize timestamps from application logs so downstream tools index events at their real event time rather than ingestion time.

Syntax

filter {
  date {
    match    => [ "logdate", "MMM dd yyyy HH:mm:ss" ]
    target   => "@timestamp"
    timezone => "America/Los_Angeles"
    locale   => "en"
    tag_on_failure => [ "_dateparsefailure" ]
  }
}

The match parameter takes a two-element array: the source field name followed by one or more date patterns. Patterns are evaluated in order; the first one that parses successfully wins.

Parameters

Examples

Parse a syslog timestamp into @timestamp:

filter {
  date {
    match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
  }
}

Parse epoch milliseconds emitted by an application logger:

filter {
  date {
    match => [ "event_time_ms", "UNIX_MS" ]
  }
}

Handle a non-UTC source without an offset, and keep the original ingestion time in a separate field:

filter {
  date {
    match    => [ "logdate", "yyyy-MM-dd HH:mm:ss" ]
    timezone => "Asia/Tokyo"
    target   => "event_time"
  }
}

Common Issues

Pattern mismatch silently tags events with _dateparsefailure rather than dropping them; check the tag in your output to catch parsing regressions. Two-digit years (yy) interpret 00-49 as 2000-2049 and 50-99 as 1950-1999, which can backdate old logs by a century. When the source string carries an offset (+0100 or Z), the timezone parameter is ignored - it only applies when the source is naive.

Locale matters: MMM parses Jan in English locale but fails on janv. from a French locale unless you set locale => "fr". If multiple date filters run on the same event, the last successful one wins for @timestamp.

Performance Notes

The plugin caches compiled patterns per filter instance, so the cost per event is the format-string evaluation, not pattern compilation. List the most common pattern first in the match array; later patterns are tried only after earlier ones fail, and failed parse attempts allocate exception objects in the JVM. For high-throughput pipelines with strict ISO 8601 inputs, prefer the literal ISO8601 keyword over a hand-written yyyy-MM-dd'T'HH:mm:ss.SSSZ pattern - the keyword path is implemented natively.

Monitoring Logstash Date Parsing with Pulse

Pulse is the only tool built specifically for monitoring and optimizing Logstash pipelines. When date parsing fails silently and events end up indexed under their ingestion time, downstream Kibana dashboards drift without anyone noticing. Pulse tracks the rate of _dateparsefailure tagged events per pipeline, alerts on regressions, and correlates them with recent grok or input plugin changes - so you catch broken date patterns the same hour they ship, not the next morning when dashboards are wrong.

Frequently Asked Questions

Q: What is the default target field for the Logstash date filter?
A: The date filter writes to @timestamp by default. Set target => "some_field" to write to a different field instead, which is useful when you want to keep the ingestion @timestamp and store the parsed event time alongside it.

Q: How do I handle multiple date formats in a single Logstash date filter?
A: List every format inside the match array after the field name: match => [ "logdate", "ISO8601", "MMM dd yyyy HH:mm:ss", "yyyy-MM-dd HH:mm:ss" ]. Logstash tries them in order and stops at the first match.

Q: How does the Logstash date filter handle timezones?
A: If the source string contains a timezone offset, that offset is used and the timezone parameter is ignored. If the source is naive, the timezone parameter is applied. The parsed value is always stored as UTC internally; Kibana renders it back to the browser timezone.

Q: What happens when the Logstash date filter fails to parse?
A: The event is tagged with _dateparsefailure (configurable via tag_on_failure) and passes through unchanged. The original @timestamp set at input time is preserved. Filter on the tag in your output to route failures to a DLQ.

Q: Can I parse UNIX epoch seconds with the date filter?
A: Yes - use the special keyword UNIX for seconds since epoch (integer or float) and UNIX_MS for milliseconds since epoch. Both accept numeric or stringified values.

Q: Why does my date filter parse correctly but show the wrong time?
A: The most common cause is a missing or wrong timezone parameter when the source string has no offset. Logstash defaults to the JVM's system timezone, which on container hosts is often UTC even when logs are local time.

Related Reading

• Logstash Grok Filter Plugin: extract the date field before parsing it.
• Logstash Dissect Filter Plugin: faster alternative to grok for fixed-format timestamps.
• Logstash JSON Filter Plugin: parse JSON-wrapped timestamps before passing to date.
• Logstash Pipeline is Blocked Error: how slow filters affect throughput.