The rewrite for the date range query has three cases:

1. DISJOINT - query is rewritten to a match none query
2. WITHIN - query is rewritten as an unbounded ([null TO null]) date range query
3. INTERSECTS - query is not rewritten and this is returned

Because we don't rewrite the query in the 3rd case above we miss the opportunity to have the query returned in a normalised (UTC milliseconds) form. This means the following cases (and possibly others I haven't thought of) will result in cache misses when the queries are actually the same:

• Two users submit queries in different timezones which map to the same UTC time range. For example, user A searches for [9pm TO 10pm] GMT and user B searches for [10pm TO 11pm] CET, both queries actually map to [9pm TO 10pm] UTC when run on the shard.
• Two users search for the same time range but with different valid date formats (because we allow multiple date formats to be used). For example, user A searches for [2012-01-01 TO 2014-01-01] and user B searches for [01/01/2012 TO 01/01/2014].
• One user searches for a date math expression using now that maps directly to another users exact search. For example, user A searches for [2016-01-01 TO 2017-01-01] and user B searches for [now-1y/y TO now/y]

In all of these cases we can use the same solution; in the INTERSECTS case we can rewrite the query so the timezone is UTC and the from and to values are in epoch milliseconds. Then the query we be more likely to cause a hit on the cache.