Influxdb: window provides incorrect _start and _stop for offset negative

Created on 3 Jun 2020  路  6Comments  路  Source: influxdata/influxdb

__Steps to reproduce:__

  1. Put some data in two different months.
    My test data:
    ,result,table,_start,_stop,_time,_value,_field,_measurement
    ,,0,2020-03-31T22:00:00Z,2020-06-01T15:02:25Z,2020-04-10T12:00:00Z,1,data,test1
    ,,0,2020-03-31T22:00:00Z,2020-06-01T15:02:25Z,2020-04-20T12:00:00Z,2,data,test1
    ,,0,2020-03-31T22:00:00Z,2020-06-01T15:02:25Z,2020-05-10T12:00:00Z,3,data,test1
    ,,0,2020-03-31T22:00:00Z,2020-06-01T15:02:25Z,2020-05-20T12:00:00Z,4,data,test1
  1. Make a Flux query with a window with periode=1mo and offset negative.
    My test query:
    from(bucket: "test")
    |> range(start: 2020-04-01T00:00:00Z, stop:2020-06-01T00:00:00Z )
    |> filter(fn: (r) => r["_measurement"] == "test1")
    |> window(period: 1mo, offset: -2h)

__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:__

  • System info: Linux 4.15.0-1081-oem x86_64
  • InfluxDB version: InfluxDB 2.0.0-beta.10 (git: d00706dea8) build_date: 2020-06-03T15:52:34Z
  • Other relevant environment details: docker image from quay.io/influxdb/influxdb:2.0.0-beta
areflux kinbug teaquery

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?

All 6 comments

@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?

Was this page helpful?
0 / 5 - 0 ratings