Skip to content

Correct the date_bin timezone statement in IoTDBTableTimeseriesDao's Javadoc #124

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.

Sign up for GitHub

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

Open
PDGGK wants to merge 1 commit into
base: master
Choose a base branch
from
+10 −8
Open

Correct the date_bin timezone statement in IoTDBTableTimeseriesDao's Javadoc #124

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 10 additions & 8 deletions ...able/src/main/java/org/apache/iotdb/extras/thingsboard/table/IoTDBTableTimeseriesDao.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -389,14 +389,16 @@ private ReadTsKvQueryResult readMillisecondsAggregatedQuery(
* <p>IoTDB 2.0.8's native {@code date_bin} calendar primitive cannot reproduce ThingsBoard's
* boundaries: it anchors each calendar bucket on the <em>origin's day-of-month</em> (so {@code
* date_bin(1mo, time, startTs)} from a mid-month {@code startTs} steps day-15 → day-15, not to
* the 1st of each month) and it exposes <em>no timezone argument</em> (it computes in the
* server's UTC zone only). ThingsBoard instead advances {@code startTs} to the start of the next
* calendar unit in {@code tzId} via {@link TimeUtils#calculateIntervalEnd}, so the first bucket
* is the partial {@code [startTs, nextCalendarBoundary)} and later buckets are full calendar
* units. This path therefore reproduces ThingsBoard exactly the way ThingsBoard itself does: it
* walks the calendar boundaries in Java and issues one bounded aggregate query per bucket
* (ThingsBoard issues one future per bucket), reusing the very same projection, row mapper and
* typed-COUNT logic as the {@code MILLISECONDS} path.
* the 1st of each month) and it exposes <em>no timezone argument</em> — its calendar arithmetic
* runs in the <em>session's</em> zone, which is fixed when the session pool is built and cannot
* be rebound per query, while each {@link ReadTsKvQuery} carries its own {@code tzId}.
* ThingsBoard instead advances {@code startTs} to the start of the next calendar unit in {@code
* tzId} via {@link TimeUtils#calculateIntervalEnd}, so the first bucket is the partial {@code
* [startTs, nextCalendarBoundary)} and later buckets are full calendar units. This path therefore
* reproduces ThingsBoard exactly the way ThingsBoard itself does: it walks the calendar
* boundaries in Java and issues one bounded aggregate query per bucket (ThingsBoard issues one
* future per bucket), reusing the very same projection, row mapper and typed-COUNT logic as the
* {@code MILLISECONDS} path.
*
* <p>Walking {@code [startTs, endPeriod)} where {@code endPeriod = max(startTs + 1, endTs)}: each
* iteration takes {@code bucketStart = startPeriod}, {@code bucketEnd = min(calculateIntervalEnd(
Expand Down