Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

puzzled time with aggregateWindow() function #5485

Open
ccbellflower opened this issue May 30, 2024 · 9 comments
Open

puzzled time with aggregateWindow() function #5485

ccbellflower opened this issue May 30, 2024 · 9 comments

Comments

@ccbellflower
Copy link

ccbellflower commented May 30, 2024

Raw data are inserted every 30s. so when the interval param, every, is set in minutes, every interval should have value, the time of which .But that's not.

  • When every is setted to "7m", data is retrieved from 00:03:59, which should be "00:08:59"

  • When every is setted to "8m", data is retrieved from 00:07:59

@ccbellflower
Copy link
Author

code referred to as below:
from(bucket: "bucket") |> range(start: 2024-05-29T16:01:00.000Z, stop: 2024-05-29T16:30:00.000Z) |> filter(fn: (r) => r["_measurement"] == "measurement") |> filter(fn: (r) => r["_field"] == "pi01") |> aggregateWindow(every: 8m, fn: last, createEmpty: false, timeSrc: "_time", // offset: 1m ) |> yield(name: "last")

@sanderson
Copy link
Contributor

@ccbellflower Window boundaries originate at the Unix epoch and are calculated based on that starting point. So window boundaries will be started every 7-8 minutes starting at 1970-01-01T00:00:00Z. I'm curious to see what your actual window boundaries are in your query. Run the following to get the start boundary of each window:

from(bucket: "bucket")
    |> range(start: 2024-05-29T16:01:00.000Z, stop: 2024-05-29T16:30:00.000Z)
    |> filter(fn: (r) => r["_measurement"] == "measurement")
    |> filter(fn: (r) => r["_field"] == "pi01")
    |> window(every: 8m, createEmpty: true)
    |> unique(column: "_start")

@influxdata influxdata deleted a comment from ccbellflower May 30, 2024
@ccbellflower
Copy link
Author

@sanderson could you please check data in this link, because i have failed to post screenshoots on this comment.
And i dont think wind boundaries based on starting point referring to this link

@sanderson
Copy link
Contributor

@ccbellflower Thanks for the link to the community post. When I query for the actual window boundaries that are being used in your query (limited to the time range you defined), I get the following:

7m windows

_start _stop
2024-05-29T16:01:00Z 2024-05-29T16:04:00Z
2024-05-29T16:04:00Z 2024-05-29T16:11:00Z
2024-05-29T16:11:00Z 2024-05-29T16:18:00Z
2024-05-29T16:18:00Z 2024-05-29T16:25:00Z
2024-05-29T16:25:00Z 2024-05-29T16:30:00Z

8m windows

_start _stop
2024-05-29T16:01:00Z 2024-05-29T16:08:00Z
2024-05-29T16:08:00Z 2024-05-29T16:16:00Z
2024-05-29T16:16:00Z 2024-05-29T16:24:00Z
2024-05-29T16:24:00Z 2024-05-29T16:30:00Z

The last function you're using in aggregateWindow() is a selector function that doesn't change the timestamp of the row that is returned for each window. The timestamp in your results is the original timestamp associated with the last row in each window. To modify the timestamp for each window, you need to use an aggregate function or define a custom function that replaces the timestamp of the last row with the boundary of the window.

@ccbellflower
Copy link
Author

@sanderson thanks for your reply.
But what I am describing is that the time returned is not the original timestamp associated with the last row in each wind.
data are inserted into every 30s, so there is one piece of data at least every minute. So when every is 7m and timeSrc is _time, 2024-05-30 00:06:59GMT+8 is the actual data rather than 2024-05-30 00:03:59GMT+8.

Copy link

github-actions bot commented Aug 7, 2024

This issue has had no recent activity and will be closed soon.

@ccbellflower
Copy link
Author

ccbellflower commented Aug 7, 2024 via email

Copy link

github-actions bot commented Oct 7, 2024

This issue has had no recent activity and will be closed soon.

@ccbellflower
Copy link
Author

ccbellflower commented Oct 7, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants