Using Date Math in Elasticsearch: Syntax and Examples

Date math is Elasticsearch's compact syntax for expressing relative dates inside queries, index names, and aggregations. An expression like now-1d/d means "the start of yesterday", evaluated at query time. Use it for time-range queries against time-series indices, for resolving date-based index names in the search path, and for date histogram bucketing windows.

Date Math Syntax

A date math expression has three parts:

<anchor>||<math>[/round]

• Anchor: either now (current time at request) or an absolute date in || form (e.g. 2026-05-13||).
• Math: a sequence of +N<unit> or -N<unit> operations.
• Round: optional /<unit> rounds the result down to the start of that unit.

If the anchor is now, the || separator is omitted.

Worked examples:

Rounding is exclusive on the upper bound and inclusive on the lower bound when used in range queries - now/d to now/d+1d returns today's data.

Date Math in Range Queries

The most common use case is filtering time-series data:

GET /logs-*/_search
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "now-7d/d",
        "lt":  "now/d"
      }
    }
  }
}

That query selects documents from the start of seven days ago up to (but not including) midnight today.

For dashboards that should "settle" on whole-day buckets, always round (/d) to make the query cacheable. Without rounding, every request has a slightly different now value and the filter cache cannot reuse results.

Date Math in Index Names

Time-series workloads often write to date-based indices (logs-2026.05.13). Date math in index names resolves the name at request time:

GET /<logs-{now/d}>/_search
GET /<logs-{now-1d/d}>/_search

The path must be URL-encoded:

GET /%3Clogs-%7Bnow%2Fd%7D%3E/_search

A custom format can be specified:

GET /<logs-{now/d{yyyy.MM.dd|UTC}}>/_search

This pattern is less common since data streams replaced manual date-based index naming in most production setups, but it still appears in long-running pipelines and custom rollover schemes.

Time Zones in Date Math

Date math operates in UTC by default. To round to local-time boundaries (e.g. "start of yesterday in Europe/Berlin"), pass time_zone on the range query:

GET /logs-*/_search
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "now-1d/d",
        "lt":  "now/d",
        "time_zone": "Europe/Berlin"
      }
    }
  }
}

The time_zone parameter only affects how the rounding boundary is computed, not the stored values. Daylight saving transitions are handled correctly when a named zone is used; fixed offsets (+02:00) are not DST-aware.

Date Math in Aggregations

Date math is also accepted in date range aggregations and as bucket boundaries in date histograms:

GET /logs-*/_search
{
  "size": 0,
  "aggs": {
    "last_24h": {
      "date_range": {
        "field": "@timestamp",
        "ranges": [ { "from": "now-24h/h", "to": "now" } ]
      }
    }
  }
}

Common Mistakes

1. Lowercase m vs uppercase M. m is minute, M is month. now-1m is one minute ago; now-1M is one month ago. Mixing them up is the most common bug.
2. Forgetting the /d round on cacheable dashboards. Without rounding, the filter changes every request and cache hit rate drops to zero.
3. Embedding date math in terms query values. Date math only works in date-aware contexts (range queries, date aggregations, index names). It is not evaluated inside a term query.
4. Treating round-down as round-to-nearest. /d always rounds down to the start of the day. To get "end of today", use now/d+1d-1s or, more commonly, lt: now/d+1d.
5. Date math with a non-date field. The mapping must be date (or date_nanos). Date math against keyword or text does not work.

Operating Time-Series Queries in Production

Date math is cheap on its own, but the queries it enables (large range filters across hundreds of time-series indices) are not. Two patterns matter for performance: always round date-math expressions to a unit appropriate for the dashboard refresh rate (so the filter cache hits), and pin time-range queries to the smallest matching index pattern (so the coordinating node does not fan out to indices that cannot match). Pulse Query Analytics profiles time-range queries hitting the cluster, surfaces dashboards that miss the filter cache because of un-rounded now, and recommends index-pattern fixes that cut fan-out cost.

Frequently Asked Questions

Q: How does Elasticsearch date math handle daylight saving time?
A: Date math computes in UTC by default. To round to local-time boundaries that respect DST, pass time_zone: "<IANA zone>" on the range query. Fixed offsets (+02:00) are not DST-aware; named zones (Europe/Berlin) are.

Q: What is the difference between now-1m and now-1M in date math?
A: now-1m is one minute ago. now-1M is one month ago. Lowercase m means minute; uppercase M means month. The case sensitivity catches almost everyone the first time.

Q: Can I use date math inside index names?
A: Yes. Wrap the index in angle brackets and use the URL-encoded form: GET /%3Clogs-%7Bnow%2Fd%7D%3E/_search. The name resolves at request time. Most modern time-series setups use data streams instead, which hide this complexity.

Q: Why does my dashboard miss the filter cache when using date math?
A: An un-rounded now produces a different value on every request, so the resulting filter is unique each time and is not cacheable. Always round to a granularity appropriate for your refresh rate - now-15m/15m is a good compromise between freshness and cache hit rate.

Q: Does date math affect query performance?
A: The expression itself is essentially free. What matters is the range it produces. A query for now-30d against an index pattern matching every daily index in the cluster still has to fan out to every match shard. Date math in conjunction with index lifecycle management is the standard way to keep that fan-out bounded.

Q: Can date math be combined with custom date formats?
A: Date math has a fixed syntax (now-1d/d), but you can specify the output format inside index-name templates using {now/d{yyyy.MM.dd|UTC}}. For query bodies, the format parameter on a range clause controls how absolute date strings are parsed.

Q: Can I use date math in date histogram aggregations?
A: Yes, in the bucket boundaries via the extended_bounds and hard_bounds parameters, and in any embedded range filter aggregations. The calendar_interval and fixed_interval parameters use plain unit specifications, not full date math expressions.

Related Reading

• Range Query: the most common consumer of date math.
• Date Histogram Aggregation: time bucketing for charts.
• Date Range Aggregation: named ranges with date math boundaries.
• Elasticsearch Query Language: the Query DSL reference.
• Index Lifecycle Management: the modern replacement for date-based index naming.
• Rollover Alias: how rollover-driven naming compares to date-math index names.