<p dir="auto"><strong>Describe the feature</strong>:<br>
Currently <code class="notranslate">epoch_millis</code> has what appears to be an arbitrary 13 character upper limit on what can be parsed. The <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-date-format.html" rel="nofollow">date format documentation</a> indicates that the year range is between 1653 and 2286, and that you should use a different formatter if your values exceed that range.</p>
<p dir="auto">Because <code class="notranslate">epoch_seconds</code> is a subset of the <code class="notranslate">epoch_millis</code> format, it too has a strange upper limit of 10 characters.</p>
<p dir="auto">We commonly receive (incorrect) data with epoch millisecond values with more than 13 characters.</p>
<p dir="auto">For <code class="notranslate">epoch_millis</code>, one might assume this low number of digits is an attempt to prevent 32 signed int overflow, but that doesn't compute.</p>
<p dir="auto">Max signed 32 bit int is 2147483647, which is 10 digits.</p>
<p dir="auto">The underlying library used by Elasticsearch for Date parsing is Joda Time, and uses <code class="notranslate">DateTime(millis, DateTimeZone.UTC)</code> to construct an immutable DateTime value from <code class="notranslate">epoch_millis</code> , where <code class="notranslate">millis</code> is a Java Long value. <code class="notranslate">millis</code> can certainly accept more than 13 chars of digits.</p>
<p dir="auto">Cross-post alert:<br>
I've asked this question in the <a href="https://discuss.elastic.co/t/epoch-millis-has-a-maximum-of-13-digits-joda-time-accepts-a-long/50508" rel="nofollow">discussion forums</a> as well.</p>
<p dir="auto">I have a PR ready to submit, pending the outcome of this discussion.</p>
<p dir="auto">The suggester API is a good choice to get simple suggestions. But these suggestions may take additional informations into account. Typing in something like <code class="notranslate">restaurant</code> will result in restaurants all over the world. But in this case the geolocation of the request can be used to get better results, namely those which are close to point of the request. Another usecase could be a simple <code class="notranslate">type</code> or <code class="notranslate">group</code> information which allows the suggester to return results fitting this context.<br>
In general the suggester should be able to handle generic information and create result with this information taken into account.</p>