__Steps to reproduce:__
__Expected behavior:__
I expect to obtain two tables with
_start = 2020-03-30T22:00:00Z _stop = 2020-04-30T22:00:00Z
_start = 2020-04-30T22:00:00Z _stop = 2020-05-30T22:00:00Z
__Actual behavior:__
The actual results are:
,result,table,_start,_stop,_time,_value,_field,_measurement
,,0,2020-04-01T08:30:00Z,2020-05-01T08:30:00Z,2020-04-10T12:00:00Z,1,data,test1
,,0,2020-04-01T08:30:00Z,2020-05-01T08:30:00Z,2020-04-20T12:00:00Z,2,data,test1
,,1,2020-04-30T08:30:00Z,2020-05-31T08:30:00Z,2020-05-10T12:00:00Z,3,data,test1
,,1,2020-04-30T08:30:00Z,2020-05-31T08:30:00Z,2020-05-20T12:00:00Z,4,data,test1
where _start and _stop boundaries are incorrect.
__Environment info:__
@robot-acladera thanks for the issue. Could you confirm that you still see this in Beta-13?
I checked in version 2.0.0-beta.13 (git: 86796ddf2d) and the issue is the same.
@robot-acladera @nathanielc @russorat
Exact same issue here.
Same offset (Europe/Paris), same precision (1mo), same results, and always these strange 08:30UTC start instead of 22:00UTC start, except the fact that I query a one year range.
This query gives me very strange results, sometimes two dates in the same month, it seems that some months are considered to start at 02 instead of 01, even if the very first date field is always correct (22:00UTC).
Did someone find a solution or any workaround ?
This is still present in the current version of InfluxDB Cloud. Given that there doesn't seem to a reasonable workaround, this is a showstopper level bug for problems like handling time zones properly. When will it be investigated?
We have been investigating this bug along with some other related ones. We found the root cause of the bugs and have a set of issues planned to fix them starting soon. See for the first issue https://github.com/influxdata/flux/issues/3323 The fix to these bugs is a small refactor to the internal mechanisms for handling times and durations.
@nathanielc That's good news. Is there an estimate for when the fix will be released?
Most helpful comment
This is still present in the current version of InfluxDB Cloud. Given that there doesn't seem to a reasonable workaround, this is a showstopper level bug for problems like handling time zones properly. When will it be investigated?