I want to retrieve data from a specific period of time

import “date”

from(bucket: “bucket”)
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r[“_measurement”] == “1m”)
|> filter(fn: (r) => r[“stockCd”] == “stockCd”)
|> filter(fn: (r) => date.hour(t: date.add(d: 30m, to:r._time)) <7 )
|> pivot(rowKey:[“_time”], columnKey: [“_field”], valueColumn: “_value”)

I want to view only data before 3:30 in UTC.
So, 30 minutes were added to the record’s time so that only data whose hour data was less than 7 could be searched.
By doing so, I was able to obtain the desired results, but query performance was significantly lowered. Is there a better way?

@rlagudcks132 I assume you’re doing a multi-day query (if you weren’t, you could just explicitly define the query time range in range(). Flux does have an hourSelection() function that filters based on hour of the day, but it only supports whole hours, not half hours. I’m wondering if the following would be any more performant:

import “date”

from(bucket: “bucket”)
    |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
    |> filter(fn: (r) => r[“_measurement”] == “1m”)
    |> filter(fn: (r) => r[“stockCd”] == “stockCd”)
    |> hourSelection(start: 0, stop: 4)
    |> filter(fn: (r) => date.hour(t: r._time) < 3 or (date.hour(t: r._time) == 3 and date.minute(t: r._time) <= 30))
    |> pivot(rowKey:[“_time”], columnKey: [“_field”], valueColumn: “_value”)

The only reason I think it could be is that the 3rd filter() is operating on less data than in your query, but I don’t know if it will change much.

Thank you for answer :slight_smile:
However, when I used the filter query you taught me,
I was able to get the result of querying data from 0 to 30 minutes of every hour from 9 to 16, rather than the data between 9 and 15:30 as I wanted.

@rlagudcks132 Can you share your full query?

Oh, I set the parentheses incorrectly and didn’t get the results I wanted. After modifying and running it again,
The query you taught me gave me the data I wanted.
Compared to existing query response speeds, we were able to obtain faster results at 0.5 from 0.7 seconds. thank you