You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@iotdb.apache.org by cr...@apache.org on 2026/08/17 07:44:28 UTC
(iotdb-extras) branch master updated: Correct the date_bin timezone statement in IoTDBTableTimeseriesDao's Javadoc (#124)
This is an automated email from the ASF dual-hosted git repository.
CritasWang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/iotdb-extras.git
The following commit(s) were added to refs/heads/master by this push:
new 49035fc Correct the date_bin timezone statement in IoTDBTableTimeseriesDao's Javadoc (#124)
49035fc is described below
commit 49035fcc01f485d9047b713b45dca85b95dc581c
Author: ZIHAN DAI <99...@users.noreply.github.com>
AuthorDate: Mon Aug 17 17:44:24 2026 +1000
Correct the date_bin timezone statement in IoTDBTableTimeseriesDao's Javadoc (#124)
The Javadoc said date_bin "computes in the server's UTC zone only". That is
wrong: DateBinFunctionColumnTransformer does its calendar arithmetic in a
ZoneId, and ColumnTransformerBuilder passes context.sessionInfo.getZoneId()
identically at v2.0.8 and on master. It was never UTC-only.
The surrounding design decision is unchanged, but its reason is different and
this is the accurate one: the zone is session-scoped and fixed when the session
pool is built, so a pooled session cannot rebind it per query, while each
ReadTsKvQuery carries its own tzId. Walking the calendar boundaries in Java
remains necessary.
Comment-only change.
Co-authored-by: Zihan Dai <dz...@gmail.com>
---
.../thingsboard/table/IoTDBTableTimeseriesDao.java | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/iotdb-thingsboard-table/src/main/java/org/apache/iotdb/extras/thingsboard/table/IoTDBTableTimeseriesDao.java b/iotdb-thingsboard-table/src/main/java/org/apache/iotdb/extras/thingsboard/table/IoTDBTableTimeseriesDao.java
index 96387db..f7c9a27 100644
--- a/iotdb-thingsboard-table/src/main/java/org/apache/iotdb/extras/thingsboard/table/IoTDBTableTimeseriesDao.java
+++ b/iotdb-thingsboard-table/src/main/java/org/apache/iotdb/extras/thingsboard/table/IoTDBTableTimeseriesDao.java
@@ -389,14 +389,16 @@ public class IoTDBTableTimeseriesDao extends IoTDBTableBaseDao
* <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(