Skip to content

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

Open
PDGGK wants to merge 1 commit into
apache:masterfrom
PDGGK:fix/date-bin-javadoc-timezone
Open

Correct the date_bin timezone statement in IoTDBTableTimeseriesDao's Javadoc#124
PDGGK wants to merge 1 commit into
apache:masterfrom
PDGGK:fix/date-bin-javadoc-timezone

Conversation

@PDGGK

@PDGGK PDGGK commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

The calendar-aggregation Javadoc I added in #115 says date_bin

exposes no timezone argument (it computes in the server's UTC zone only).

The first half is right; the parenthetical is wrong, and it was wrong when I wrote it rather than having gone stale.

DateBinFunctionColumnTransformer.dateBin(long source, long origin, int monthDuration, long nonMonthDuration, ZoneId zoneId) converts through LocalDateTime in that ZoneId, and ColumnTransformerBuilder's DATE_BIN branch passes context.sessionInfo.getZoneId() — identically at v2.0.8 (the version the Javadoc names) and on master. It has never been UTC-only. TableSessionPoolBuilder.zoneId(...) even defaults to ZoneId.systemDefault(), so UTC is not the default either.

The design decision the paragraph justifies does not change: this path still has to walk calendar boundaries in Java. But the accurate reason is different, and it is a stronger one — the zone is session-scoped, fixed when the session pool is built, so a pooled session cannot rebind it per query, whereas each ReadTsKvQuery carries its own tzId. The day-of-month anchoring half of the original sentence stands unchanged.

Comment-only change; no behaviour is affected. Verified mvn -P with-thingsboard compile and applied spotless:apply (which reflowed the surrounding paragraph, hence the slightly larger diff).

…Javadoc

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.
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

Successfully merging this pull request may close these issues.

1 participant