<p dir="auto"><code class="notranslate">Granularity.getIterable(Interval)</code> returns an iterable of chunked intervals by the granularity. For example, <code class="notranslate">DAY.getIterable(Intervals.of("2019-01-01/2019-01-03"))</code> returns <code class="notranslate">2019-01-01/2019-01-02</code> and <code class="notranslate">2019-01-02/2019-01-03</code>. This method is currently being used in indexing service (<code class="notranslate">UniformGranularitySpec</code>) as well as query processing (<code class="notranslate">makeCursors()</code> in <code class="notranslate">QueryableIndexStorageAdapter</code> and <code class="notranslate">IncrementalIndexStorageAdapter</code>).</p>
<p dir="auto">But, the current behavior of this method is somewhat different from my expectation. The endTime of the last interval is not bound by the input interval. For example, <code class="notranslate">DAY.getIterable(Intervals.of("2019-01-01T00:00:00/2019-01-03T12:00:00"))</code> returns the below 3 intervals.</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="2019-01-01T00:00:00.000Z/2019-01-02T00:00:00.000Z
2019-01-02T00:00:00.000Z/2019-01-03T00:00:00.000Z
2019-01-03T00:00:00.000Z/2019-01-04T00:00:00.000Z"><pre class="notranslate"><code class="notranslate">2019-01-01T00:00:00.000Z/2019-01-02T00:00:00.000Z
2019-01-02T00:00:00.000Z/2019-01-03T00:00:00.000Z
2019-01-03T00:00:00.000Z/2019-01-04T00:00:00.000Z
</code></pre></div>
<p dir="auto">The last interval is <code class="notranslate">2019-01-03/2019-01-04</code> is not contained the input interval <code class="notranslate">2019-01-01T00:00:00/2019-01-03T12:00:00</code>.</p>
<p dir="auto">Sometimes, even the startTime of the first interval is not bound too. <code class="notranslate">WEEK.getIterable(Intervals.of("2019-01-01/2019-01-11"))</code> returns</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="2018-12-31T00:00:00.000Z/2019-01-07T00:00:00.000Z
2019-01-07T00:00:00.000Z/2019-01-14T00:00:00.000Z"><pre class="notranslate"><code class="notranslate">2018-12-31T00:00:00.000Z/2019-01-07T00:00:00.000Z
2019-01-07T00:00:00.000Z/2019-01-14T00:00:00.000Z
</code></pre></div>
<p dir="auto">This is because <a href="https://github.com/apache/incubator-druid/blob/master/core/src/main/java/org/apache/druid/java/util/common/granularity/PeriodGranularity.java#L283">PeriodGranularity sets the start day to Monday</a>.</p>
<p dir="auto">I'm not sure this makes sense. The query result may contain timestamps of not specified in the query spec which can mislead users. This can be even worse when it comes to indexing because reindexing tasks can overshadow segments unexpectedly.</p>
<p dir="auto">I think probably it's better to clip off the end time of the last interval (and maybe the start time of the first interval too), but not sure what was the initial intention.</p>
<p dir="auto">Any thoughts?</p>
<h3 dir="auto">Description</h3>
<p dir="auto">Protobuf has a native timestamp type, defined <a href="https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/timestamp.proto">here</a>.</p>
<h3 dir="auto">Motivation</h3>
<p dir="auto">Timestamps being passed around in protobuf bytes are using the native <code class="notranslate">timestamp</code> format and moving these to druid ingestion necessitates the duplication of that timestamp in a string.</p>