Date field types in Elasticsearch - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this date mapping query?

Given this Elasticsearch mapping for a date field, what will be the stored format of the date?

{
  "mappings": {
    "properties": {
      "created_at": {
        "type": "date",
        "format": "yyyy-MM-dd HH:mm:ss||epoch_millis"
      }
    }
  }
}

Elasticsearch

POST /my_index/_doc
{
  "created_at": "2024-06-15 14:30:00"
}

A The date is parsed and stored as milliseconds since epoch (epoch_millis)

B The date is stored as a string exactly as "2024-06-15 14:30:00"

C The date is stored as a Unix timestamp in seconds

D The date is stored as a text field without parsing

💡 Hint

Check the format property and how Elasticsearch parses dates.

Elasticsearch parses the date string using the specified format and stores it internally as epoch milliseconds for efficient range queries and sorting.

❓ Predict Output

intermediate

What happens if a date does not match the format?

Consider this mapping:

{
  "mappings": {
    "properties": {
      "event_date": {
        "type": "date",
        "format": "yyyy/MM/dd"
      }
    }
  }
}

What happens if you index a document with:

{ "event_date": "2024-06-15" }

A Elasticsearch throws a parsing exception and rejects the document

B The event_date field is stored as null

C Elasticsearch stores the date as a string without parsing

D The document is indexed successfully with event_date parsed as 2024-06-15

💡 Hint

The date format must exactly match the input string.

Since the input date "2024-06-15" does not match the format "yyyy/MM/dd", Elasticsearch cannot parse it and rejects the document with an error.

🔧 Debug

advanced

Why does this date mapping cause an error?

This mapping causes an error when creating the index:

{
  "mappings": {
    "properties": {
      "log_time": {
        "type": "date",
        "format": "strict_date_optional_time||epoch_millis||yyyy-MM-dd HH:mm:ss"
      }
    }
  }
}

What is the cause of the error?

A The format string is missing a separator between formats

B The format string uses an invalid date pattern with spaces

C The format string is too long and exceeds Elasticsearch limits

D The format string mixes strict and non-strict formats causing a conflict

💡 Hint

Check how strict_date_optional_time interacts with other formats.

Using strict_date_optional_time with other formats in the same format string causes conflicts because strict formats enforce strict parsing rules that clash with others.

🧠 Conceptual

advanced

How does Elasticsearch handle multiple date formats in one field?

If a date field mapping specifies multiple formats separated by ||, how does Elasticsearch process an incoming date string?

A It requires the date string to match all formats simultaneously

B It uses only the first format and ignores the rest

C It tries each format in order until one matches the date string

D It randomly picks one format to parse the date string

💡 Hint

Think about how flexible date parsing works.

Elasticsearch attempts to parse the date string using each format in order until one succeeds, allowing flexible input formats for the same field.

❓ Predict Output

expert

What is the output of this date range query?

Given this mapping and documents:

{
  "mappings": {
    "properties": {
      "timestamp": {
        "type": "date",
        "format": "epoch_millis"
      }
    }
  }
}

POST /my_index/_bulk
{ "index": {} }
{ "timestamp": 1686787200000 }
{ "index": {} }
{ "timestamp": 1686873600000 }

What documents match this query?

{
  "query": {
    "range": {
      "timestamp": {
        "gte": "1686787200000",
        "lt": "1686873600000"
      }
    }
  }
}

A No documents match

B Only the first document matches

C Both documents match

D Only the second document matches

💡 Hint

Check the range boundaries and timestamp values carefully.

The range query includes documents with timestamp >= 1686787200000 and < 1686873600000. The first document matches exactly the lower bound, the second equals the upper bound which is exclusive, so it does not match.