# Limitation of storing documents with a timestamp far far in the future

**URL:** <https://discuss.elastic.co/t/limitation-of-storing-documents-with-a-timestamp-far-far-in-the-future/216299>\
**Category:** Elasticsearch\
**Created:** [January 23, 2020, 4:56pm UTC](https://discuss.elastic.co/t/limitation-of-storing-documents-with-a-timestamp-far-far-in-the-future/216299 "2020-01-23T16:56:19Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![fim](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fim/32/90645_2.png) [@fim](https://discuss.elastic.co/u/fim)\
**Post date:** [January 23, 2020, 4:56pm UTC](https://discuss.elastic.co/t/limitation-of-storing-documents-with-a-timestamp-far-far-in-the-future/216299/1 "2020-01-23T16:56:19Z")

</div>

Hi Community

The @timestamp field of an index template has been set in the format of epoch\_seconds.  
Unfortunately the application sends the data in epoch\_millis (1577983263046).  
Hence the json events are stored somewhere in year 04/20/51974.

I've queried the data for results @timestamp higher than today, but I couldn't find events.  
From my point of view it looks that elasticsearch skips such documents.

My question: Of course our scenario is an application issue but nevertheless I'm wondering whether there is a limitation storing documents far in the future? Is there?

Thanks

---

<div class="post-metadata">

**Author:** ![Magnus\_Kessler](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/magnus_kessler/32/42001_2.png) [@Magnus\_Kessler](https://discuss.elastic.co/u/Magnus_Kessler)\
**Post date:** [January 23, 2020, 5:32pm UTC](https://discuss.elastic.co/t/limitation-of-storing-documents-with-a-timestamp-far-far-in-the-future/216299/2 "2020-01-23T17:32:55Z")

</div>

No, as long as the value doesn't surpass the largest value that can stored in the underlying data structure, there is no limit on dates in the future.

This example demonstrates the behaviour. Two documents are stored, where one contains the date value as `epoch_second`, and the other as `epoch_millis`. The mapping only specifies `epoch_second` and also `basic_date_optional_time`. Only date strings in a recognized format can be searched for.

```auto
DELETE test-date
PUT test-date
{
  "mappings": {
    "properties": {
      "message": {
        "type": "text"
      },
      "@timestamp": {
        "type": "date",
        "format": "date_optional_time||epoch_second"
      }
    }
  }
}

PUT test-date/_doc/1
{
  "@timestamp": "1577983263046",
  "message": "Hello Millis"
}

PUT test-date/_doc/2
{
  "@timestamp": "1577983263",
  "message": "Hello Seconds"
}

GET test-date/_search
{
  "size": 10, 
  "query": {
    "range": {
      "@timestamp": {
        "gte": "1577983263"
      }
    }
  }
}

GET test-date/_search
{
  "size": 10, 
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2020-01-01"
      }
    }
  }
}

```

I would suggest that you adjust the mapping of your index to reflect the actual formats used in the data. You can reindex from the already existing index into a new index that has `epoch_millis` in the date format (default).

---

<div class="post-metadata">

**Author:** ![fim](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fim/32/90645_2.png) [@fim](https://discuss.elastic.co/u/fim)\
**Post date:** [January 23, 2020, 6:57pm UTC](https://discuss.elastic.co/t/limitation-of-storing-documents-with-a-timestamp-far-far-in-the-future/216299/3 "2020-01-23T18:57:15Z")

</div>

Awesome Magnus!  
Your answer helped us a lot.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [February 20, 2020, 6:57pm UTC](https://discuss.elastic.co/t/limitation-of-storing-documents-with-a-timestamp-far-far-in-the-future/216299/4 "2020-02-20T18:57:18Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.