Context:

Currently, when we create the aggregation for a report that is grouped by running date, we first need to determine the range (i.e. the covered span on the x-axis) of the buckets. To do so, we look at the earliest and latest process instances - the bucket range should start at the earliest instance start date and end at the latest instance end date, this way the entire runtime of all completed instances is covered.
In order to get this earliest start and latest end date, we get a stats aggregation on the start/end date fields of the process instances and then check the min/max values of these stats aggregations. Unfortunately, these min/max values do not include timezone offset information, so in the backend we just apply the default offset.
However, this could theoretically lead to inaccuracies in the result:

When the actual aggregation is created, we compare the instances start/end dates to the current bucket dates. The instance start/end dates in ES do have the correct timezone information, whereas the bucket dates have just assumed the default offset as described above. This means instances could end up falling in incorrect buckets or even outside the bucket span.

Example:
we have 2 instances:

• instance 1 starts 12:00:00 + 03:00, ends at 13:00:00 + 03:00,
• instance 2 starts at 13:00:00 + 03:00, ands at 14:00:00 + 03:00

The min/max stats will result in a bucket span of 12:00:00 - 14:00:00, but with the default offset, say + 0200.
Assuming a groupBy unit of hour, there will be two buckets:

• Bucket 1: 12:00:00 - 13:00:00 (both with offset +0200)
• Bucket 2: 13:00:00 - 14:00:00 (both with offest +0200)

Since timezone information is not displayed in the UI and the bucket labels will just be "12:00-13:00" and "13:00-14:00", instance 1 would be expected to fall into bucket 1 and instance 2 to fall into bucket 2, but because of the timezone difference the result will actually be that instance 2 falls into bucket 1, instance 1 won't fall into either bucket and bucket 2 will be empty.

It is also not communicated at all to the user in the UI which timezone the bucket labels are in, it looks like this also touches on the issues described in OPT-3259. 

AT:

• A solution is found that ensures that all instances are covered by the bucket span of running instance reports and fall into the correct buckets